Re: calm: cygwin package report for Brian Inglis

On 28/04/2026 21:32, Brian Inglis via Cygwin-apps wrote:
> On 2026-04-26 23:23, cygwin-no-reply- 
> [email protected] wrote:
>> INFO: package 'tzdata': errors in license expression: ['Unknown 
>> license key(s): LicenseRef-IANA-TZ-Public-Domain']
>> ERROR: package 'man-pages-linux' has non-existent keep: version '6.12-2'
>> ERROR: package 'man-pages-linux' has non-existent keep: version '6.6-1'
>> ERROR: package 'man-pages-linux' has non-existent keep: version '6.1-1'
>> ERROR: package 'man-pages-linux' has non-existent keep: version '5.15-1'
>> ERROR: package 'man-pages-linux' has non-existent keep: version '5.10-1'
>> ERROR: package 'man-pages-linux-src' has non-existent keep: version 
>> '6.12-2'
>> ERROR: package 'man-pages-linux-src' has non-existent keep: version 
>> '6.6-1'
>> ERROR: package 'man-pages-linux-src' has non-existent keep: version 
>> '6.1-1'
>> ERROR: package 'man-pages-linux-src' has non-existent keep: version 
>> '5.15-1'
>> ERROR: package 'man-pages-linux-src' has non-existent keep: version 
>> '5.10-1'
[...]
> 
> Hi folks/Jon,
> 
> Added man-pages-linux override.hint keeps intending to ensure that all 
> current and any LTS release manpages are retained until their extended 
> support expires.
> But calm or the setup infrastructure objects to references to previously 
> vaulted releases, every time I upload or deploy *any* of my packages.
> 
> So I ask, is it easy enough for someone with access to move old releases 
> from the vault back into the release area, to be worth while doing so?
> 
> Or should I upload another override.hint with the keeps reduced to the 
> current release only, extending that only as I upload/deploy packages 
> for future LTS releases?

Hmmm... I sent you an email about this when it started happening, but it 
doesn't seem to have turned up here:

> -------- Forwarded Message --------
> Subject: Re: calm: cygwin package report
> Date: Mon, 27 Apr 2026 14:02:54 +0100
> From: Jon Turney <jturney-9JcytcrH/[email protected]>
> To: [email protected]
> CC: Brian Inglis <Brian.Inglis-08AYpwWsK/NbR+1V6oSykrDks+cytr/[email protected]>
> 
> On 26/04/2026 22:01, [email protected] wrote:
>> ERROR: package 'man-pages-linux' has non-existent keep: version '6.12-2'
>> ERROR: package 'man-pages-linux' has non-existent keep: version '6.6-1'
>> ERROR: package 'man-pages-linux' has non-existent keep: version '6.1-1'
>> ERROR: package 'man-pages-linux' has non-existent keep: version '5.15-1'
>> ERROR: package 'man-pages-linux' has non-existent keep: version '5.10-1'
>> ERROR: package 'man-pages-linux-src' has non-existent keep: version '6.12-2'
>> ERROR: package 'man-pages-linux-src' has non-existent keep: version '6.6-1'
>> ERROR: package 'man-pages-linux-src' has non-existent keep: version '6.1-1'
>> ERROR: package 'man-pages-linux-src' has non-existent keep: version '5.15-1'
>> ERROR: package 'man-pages-linux-src' has non-existent keep: version '5.10-1'
>> SUMMARY: 10 ERROR(s)
> 
> I corrected the version numbers in the keep: directive to match those actually used, and restored those packages from the vault.
> 
> keep: 6.18-2  6.12-1  6.06-1  6.01-1
> 
> I had to drop '5.15-1 5.10-1' because they aren't there. The only 5.x version seems to be 5.13-1 from 09-2021.
> 
> If necessary, I can enquire if older versions are available in offline backups, but I'd like to double check that we actually made them first :).
So, hopefully this message isn't getting spammed out anymore.

I would like some clarification on how these older versions are useful.

What information do these older versions contain that the most recent 
does not? i.e. is man-pages-linux really dropping "since kernel/glibc 
x.y.z" annotations for older versions?

> And could we perhaps change calm/infrastructure to only check and 
> complain about a package override.hint when a release of that package is 
> uploaded?

Yes, there are few cases where something like that approach should be 
taken, but until recently I didn't have a mechanism for it.

In this case however, I'm not sure that the right logic:

If you vault version X which is cited as keep, you should be told about 
it then, not when the next version is uploaded.

> I am managing the override.hint in CYGWIN_FILES and manually copying it 
> from $C to .../inst/$PN/ $distdir/$PN/, before upload.
> I checked whether I could perhaps set PKG_HINTS=override but thought 
> that might suppress auto-generation of $PF-$ARCH.hint?

Yeah, don't do that.

Managing the override.hint as part of the package isn't really how 
you're intended to use it, because it can change for reasons which have 
nothing to do with any particular edition of the package.