Fwd: calm: cygwin package report for Ken Brown

Fwd: calm: cygwin package report for Ken Brown

[Ken Brown]

It looks like my plan for having scallywag deploy all the TeX Live 
packages won't work (see below).  calm would have to be more permissive 
and allow deploying a package that requires something that will be 
provided by a future package.

In this case, I made asymptote require tl_2023, which will be provided 
by the next texlive release.  But I don't want to deploy the latter 
until all the other packages for TeX Live 2023 have been deployed.

Unless this is easy to fix, I'll just forget about using scallywag and 
go back to my old method of uploading everything manually.

Ken

-------- Forwarded Message --------
Subject: calm: cygwin package report for Ken Brown
Date: Mon, 20 Mar 2023 21:57:12 -0000
From: cygwin-no-reply@cygwin.com
Reply-To: cygwin-apps@cygwin.com
To: kbrown@cornell.edu

ERROR: package 'asymptote' version '2.85-1' depends: 'tl_2023', but 
nothing satisfies that
ERROR: error while validating merged x86_64 packages for Ken Brown
SUMMARY: 2 ERROR(s)

Re: Fwd: calm: cygwin package report for Ken Brown

[Jon Turney]

On 20/03/2023 22:17, Ken Brown via Cygwin-apps wrote:
> It looks like my plan for having scallywag deploy all the TeX Live 
> packages won't work (see below).  calm would have to be more permissive 
> and allow deploying a package that requires something that will be 
> provided by a future package.
> 
> In this case, I made asymptote require tl_2023, which will be provided 
> by the next texlive release.  But I don't want to deploy the latter 
> until all the other packages for TeX Live 2023 have been deployed.
> 
> Unless this is easy to fix, I'll just forget about using scallywag and 
> go back to my old method of uploading everything manually.

This is trivially fixable.

calm already has a list of 'provides which don't exist (yet)', so I 
think I just need to add tl_2023 and tl_basic_2023 to that list

Future work: make these regexes so we don't have same problem again in a 
years time.

> 
> Ken
> 
> -------- Forwarded Message --------
> Subject: calm: cygwin package report for Ken Brown
> Date: Mon, 20 Mar 2023 21:57:12 -0000
> From: cygwin-no-reply-rDBXBDvO6BXQT0dZR+AlfA@public.gmane.org
> Reply-To: cygwin-apps-rDBXBDvO6BXQT0dZR+AlfA@public.gmane.org
> To: kbrown-HmMyXyqgL2CVc3sceRu5cw@public.gmane.org
> 
> ERROR: package 'asymptote' version '2.85-1' depends: 'tl_2023', but 
> nothing satisfies that
> ERROR: error while validating merged x86_64 packages for Ken Brown
> SUMMARY: 2 ERROR(s)

Maybe calm doesn't need to do this kind of check any more?

But then people might write REQUIRES="typoed-package-name" and not 
notice until it's uninstallable, so I don't know.

Re: Fwd: calm: cygwin package report for Ken Brown

[gs-cygwin.com]

On Mon, Mar 20, 2023 at 11:17:38PM +0000, Jon Turney via Cygwin-apps wrote:
> On 20/03/2023 22:17, Ken Brown via Cygwin-apps wrote:
> > It looks like my plan for having scallywag deploy all the TeX Live
> > packages won't work (see below).  calm would have to be more permissive
> > and allow deploying a package that requires something that will be
> > provided by a future package.
> > 
> > In this case, I made asymptote require tl_2023, which will be provided
> > by the next texlive release.  But I don't want to deploy the latter
> > until all the other packages for TeX Live 2023 have been deployed.
> > 
> > Unless this is easy to fix, I'll just forget about using scallywag and
> > go back to my old method of uploading everything manually.
> 
> This is trivially fixable.
> 
> calm already has a list of 'provides which don't exist (yet)', so I think I
> just need to add tl_2023 and tl_basic_2023 to that list
> 
> Future work: make these regexes so we don't have same problem again in a
> years time.
> 
> > 
> > Ken
> > 
> > -------- Forwarded Message --------
> > Subject: calm: cygwin package report for Ken Brown
> > Date: Mon, 20 Mar 2023 21:57:12 -0000
> > From: cygwin-no-reply-rDBXBDvO6BXQT0dZR+AlfA@public.gmane.org
> > Reply-To: cygwin-apps-rDBXBDvO6BXQT0dZR+AlfA@public.gmane.org
> > To: kbrown-HmMyXyqgL2CVc3sceRu5cw@public.gmane.org
> > 
> > ERROR: package 'asymptote' version '2.85-1' depends: 'tl_2023', but
> > nothing satisfies that
> > ERROR: error while validating merged x86_64 packages for Ken Brown
> > SUMMARY: 2 ERROR(s)
> 
> Maybe calm doesn't need to do this kind of check any more?
> 
> But then people might write REQUIRES="typoed-package-name" and not notice
> until it's uninstallable, so I don't know.

It seems to me like a useful warning, whether or not it remains an
error here.  Also, it seems to me like this check could be added to
prevent packages from being released (other than to 'test') since an
uninstallable package is an uninstallable package, though circular
dependencies could then be an issue for releasing. (Yes, avoid those!)

Cheers, Glenn

Re: Fwd: calm: cygwin package report for Ken Brown

[Ken Brown]

On 3/20/2023 7:17 PM, Jon Turney wrote:
> On 20/03/2023 22:17, Ken Brown via Cygwin-apps wrote:
>> It looks like my plan for having scallywag deploy all the TeX Live 
>> packages won't work (see below).  calm would have to be more 
>> permissive and allow deploying a package that requires something that 
>> will be provided by a future package.

[...]

> This is trivially fixable.
> 
> calm already has a list of 'provides which don't exist (yet)', so I 
> think I just need to add tl_2023 and tl_basic_2023 to that list

Thanks!

[...]

> Maybe calm doesn't need to do this kind of check any more?
> 
> But then people might write REQUIRES="typoed-package-name" and not 
> notice until it's uninstallable, so I don't know.

I don't know either, but I think I lean toward not doing the check, in 
order to give maintainers maximum flexibility.  In your example, the 
problem is easily fixed as soon as the maintainer (or someone else) 
notices that the package is uninstallable.  And when they try to select 
it for installation, setup will immediately tell them what the problem is.

Ken

Re: Fwd: calm: cygwin package report for Ken Brown

[Corinna Vinschen]

On Mar 20 23:17, Jon Turney via Cygwin-apps wrote:
> On 20/03/2023 22:17, Ken Brown via Cygwin-apps wrote:
> > It looks like my plan for having scallywag deploy all the TeX Live
> > packages won't work (see below).  calm would have to be more permissive
> > and allow deploying a package that requires something that will be
> > provided by a future package.
> > 
> > In this case, I made asymptote require tl_2023, which will be provided
> > by the next texlive release.  But I don't want to deploy the latter
> > until all the other packages for TeX Live 2023 have been deployed.
> > 
> > Unless this is easy to fix, I'll just forget about using scallywag and
> > go back to my old method of uploading everything manually.
> 
> This is trivially fixable.
> 
> calm already has a list of 'provides which don't exist (yet)', so I think I
> just need to add tl_2023 and tl_basic_2023 to that list
> 
> Future work: make these regexes so we don't have same problem again in a
> years time.

Wouldn't it make sense to be able to define this in the cygport file
somehow?  Or does that open a can of worms?


Corinna

Re: Fwd: calm: cygwin package report for Ken Brown

[Ken Brown]

On 3/20/2023 7:17 PM, Jon Turney wrote:
> On 20/03/2023 22:17, Ken Brown via Cygwin-apps wrote:
>> It looks like my plan for having scallywag deploy all the TeX Live 
>> packages won't work (see below).  calm would have to be more 
>> permissive and allow deploying a package that requires something that 
>> will be provided by a future package.
>>
>> In this case, I made asymptote require tl_2023, which will be provided 
>> by the next texlive release.  But I don't want to deploy the latter 
>> until all the other packages for TeX Live 2023 have been deployed.
>>
>> Unless this is easy to fix, I'll just forget about using scallywag and 
>> go back to my old method of uploading everything manually.
> 
> This is trivially fixable.
> 
> calm already has a list of 'provides which don't exist (yet)', so I 
> think I just need to add tl_2023 and tl_basic_2023 to that list
> 
> Future work: make these regexes so we don't have same problem again in a 
> years time.

Jon,

In preparation for TeX Live 2024, please add tl_2024 and tl_basic_2024 
to the list of provides which don't exist yet (unless you've already 
done the regex future work).

Thanks.

Ken

Re: Fwd: calm: cygwin package report for Ken Brown

[Jon Turney]

On 19/02/2024 18:59, Ken Brown via Cygwin-apps wrote:
> On 3/20/2023 7:17 PM, Jon Turney wrote:
>> On 20/03/2023 22:17, Ken Brown via Cygwin-apps wrote:
>>> It looks like my plan for having scallywag deploy all the TeX Live 
>>> packages won't work (see below).  calm would have to be more 
>>> permissive and allow deploying a package that requires something that 
>>> will be provided by a future package.
>>>
>>> In this case, I made asymptote require tl_2023, which will be 
>>> provided by the next texlive release.  But I don't want to deploy the 
>>> latter until all the other packages for TeX Live 2023 have been 
>>> deployed.
>>>
>>> Unless this is easy to fix, I'll just forget about using scallywag 
>>> and go back to my old method of uploading everything manually.
>>
>> This is trivially fixable.
>>
>> calm already has a list of 'provides which don't exist (yet)', so I 
>> think I just need to add tl_2023 and tl_basic_2023 to that list
>>
>> Future work: make these regexes so we don't have same problem again in 
>> a years time.
> 
> Jon,
> 
> In preparation for TeX Live 2024, please add tl_2024 and tl_basic_2024 
> to the list of provides which don't exist yet (unless you've already 
> done the regex future work).

These are controlled by regex now, so these should already be permitted, 
and I don't need to do anything (yay!):

     'tl_\d+'
     'tl_basic_\d+'

Re: Fwd: calm: cygwin package report for Ken Brown

[Brian Inglis]

On 2023-05-05 11:16, Jon Turney via Cygwin-apps wrote:
> On 04/05/2023 17:24, Ken Brown via Cygwin-apps wrote:
>>> INFO: package 'savi': errors in license expression: ['Unknown license
>>> key(s): BSD-Advertising-Acknowledgement']

>> Any idea why calm complained about this license key?  It's listed at
>> https://spdx.org/licenses/.

> I suspect this is because that license was added in version 3.20 of the list, 
> and the python module currently used to parse and validate the license 
> expressions only contains and older version.
> 
> It looks like maybe I need to write some stuff to automatically fetch the latest 
> list and feed it into that module...

ITP SPDX-licence-check?, then cygport and calm can depend on it, and we can all 
be the patrol cop pulling over packages to check their licences ;^>

SPDX appears to be like tzdb was years ago, with both code and data updates 
every release, so don't *have* to worry about splitting.

Good enough for calm is good enough for us, and anyone who doen't like something 
can offer patches.

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

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Re: Fwd: calm: cygwin package report for Ken Brown

[Jon Turney]

On 04/05/2023 17:24, Ken Brown via Cygwin-apps wrote:
>> INFO: package 'savi': errors in license expression: ['Unknown license
>> key(s): BSD-Advertising-Acknowledgement']
> 
> Any idea why calm complained about this license key?  It's listed at
> https://spdx.org/licenses/.

I suspect this is because that license was added in version 3.20 of the 
list, and the python module currently used to parse and validate the 
license expressions only contains and older version.

It looks like maybe I need to write some stuff to automatically fetch 
the latest list and feed it into that module...

Fwd: calm: cygwin package report for Ken Brown

[Ken Brown]

> INFO: package 'savi': errors in license expression: ['Unknown license
> key(s): BSD-Advertising-Acknowledgement']

Any idea why calm complained about this license key?  It's listed at
https://spdx.org/licenses/.

Ken