This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mksetupini fails validating packages because curr is test

Hi Jon,

Thanks for prompt actions!

I think no need to package it separately for testing, just release it
to cygwin repo.

Yes, I understand that there always is a human factor, this is why I
do all my building, version bumping up and deployment automatically by
scripts, so this check seems unnecessary in my case and good that it
can be turned off now.


2017-11-30 14:41 GMT+02:00 Jon Turney <>:
> On 30/11/2017 09:28, Ivan Gagis wrote:
>> I use git repository on github to store the files. And to update it I
>> clone the repo, run mksetupini and then commit and push.
>> So, I'm not sure what actually is going on with mtime of the files
>> there. Perhaps git messes up the mtime of cloned files.
> Yes, a git checkout will have the mtime of the checkout.
> I've pushed an update to the calm repo with these changes:
> - mksetupini and calm now exit with non-zero exit status on an error
> - Fixes a bug where equal mtime was considered newer
> - Adds 'mksetupini --disable-check=curr-most-recent' option to turn off this
> check
> Do I need to package this for you to test it?
>> But why is this check of mtime needed at all? Isn't version number
>> enough for tracking earlier-later files?
> Maybe this doesn't make much sense in the context of mksetupini, but this is
> a useful check for calm to make.
> People make mistakes.
> People also forget the subtleties of how version numbers sort and upload
> versions which aren't greater than the current version, when they think they
> are...

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]