This is the mail archive of the
mailing list for the Cygwin project.
Re: mksetupini fails validating packages because curr is test
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 <firstname.lastname@example.org>:
> 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
> 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
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple