Re: calm: cygwin package report for Brian Inglis

On 2026-04-29 06:49, Jon Turney via Cygwin-apps wrote:
> 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.

Thanks Jon,

That was not clear to me - I think I had been building my own locally and only 
started an ITP with 5.13 from what I can see.
As each release was 110-135MB each, I cleaned up 5, then 6.? locally.

>> 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?

The older releases, especially for LTS releases and syscalls, document exactly 
which interfaces and options were valid and available at that time, which would 
be especially useful for folks running RHEL and Oracle UEK distros which run 
older kernels.
I guess its a value add but whether Cygwin packaging should care could be up for 
discussion?

>> 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.

In this case, new editions of the manpages lag the kernel releases to the extent 
the kernel docs do, and the new kernel releases determine the older EoLs: the 
latest just EoLed a few earlier releases.
I keep track of these because most add some cpuid attributes, and some find 
there way into the visible /proc/cpuinfo output, both of which I am interested in.

-- 
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 à retrancher  but when there is no more to cut
                                 -- Antoine de Saint-Exupéry