mksetupini fails validating packages because curr is test

mksetupini fails validating packages because curr is test

[Ivan Gagis]

Hi,

I have an overlay cygwin repo where I publish my packages.

Recently I started getting errors from mksetupini script:

"
mksetupini: package 'mypackage' version '0.4.38-1' is most recent
non-test version, but version '0.4.43-1' is curr:
mksetupini: package set has errors, not writing setup.ini
"

there was no such errors before. And I don't have "test:" in any hint
files of my packages, so no I dea why it thinks that some versions are
non-test and curr is test?

Can you explain what this actually means?

Br,
Ivan

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: mksetupini fails validating packages because curr is test

[Jon Turney]

On 29/11/2017 15:06, Ivan Gagis wrote:
> I have an overlay cygwin repo where I publish my packages.
> 
> Recently I started getting errors from mksetupini script:
> 
> "
> mksetupini: package 'mypackage' version '0.4.38-1' is most recent
> non-test version, but version '0.4.43-1' is curr:
> mksetupini: package set has errors, not writing setup.ini
> "
> 
> there was no such errors before. And I don't have "test:" in any hint
> files of my packages, so no I dea why it thinks that some versions are
> non-test and curr is test?

It's not saying any versions are test.

> Can you explain what this actually means?

"most recent" means "latest timestamp"

So this is telling you that 0.4.38-1 is the non-test version which has 
the most recent timestamp, but 0.4.43-1 is curr: (because it's the 
highest non-test version)

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: mksetupini fails validating packages because curr is test

[Jon Turney]

On 29/11/2017 21:34, Ivan Gagis wrote:
> What is that timestamp? Is it when the package was uploaded?

Sorry, by timestamp, I just mean the mtime of the archive file.

> Then it should not be possible, because lower version definitely was
> uploaded earlier than higher version package.
> 
> Where are those timestamps kept? Hint files does not contain any
> timestamp and setup.ini only has its global timestamp, but not
> per-package timestamps.
> 
> Do you have any suggestion of how to fix this?

Assuming you've found a bug, I need some more details to enable me to 
reproduce it, before I can fix it...

> 2017-11-29 18:52 GMT+02:00 Jon Turney:
>> On 29/11/2017 15:06, Ivan Gagis wrote:
>>>
>>> I have an overlay cygwin repo where I publish my packages.
>>>
>>> Recently I started getting errors from mksetupini script:
>>>
>>> "
>>> mksetupini: package 'mypackage' version '0.4.38-1' is most recent
>>> non-test version, but version '0.4.43-1' is curr:
>>> mksetupini: package set has errors, not writing setup.ini
>>> "
>>>
>>> there was no such errors before. And I don't have "test:" in any hint
>>> files of my packages, so no I dea why it thinks that some versions are
>>> non-test and curr is test?
>>
>>
>> It's not saying any versions are test.
>>
>>> Can you explain what this actually means?
>>
>>
>> "most recent" means "latest timestamp"
>>
>> So this is telling you that 0.4.38-1 is the non-test version which has the
>> most recent timestamp, but 0.4.43-1 is curr: (because it's the highest
>> non-test version)

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: mksetupini fails validating packages because curr is test

[Ivan Gagis]

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.

But why is this check of mtime needed at all? Isn't version number
enough for tracking earlier-later files?

Br,
Ivan


2017-11-30 0:13 GMT+02:00 Jon Turney <jon.turney@dronecode.org.uk>:
> On 29/11/2017 21:34, Ivan Gagis wrote:
>>
>> What is that timestamp? Is it when the package was uploaded?
>
>
> Sorry, by timestamp, I just mean the mtime of the archive file.
>
>> Then it should not be possible, because lower version definitely was
>> uploaded earlier than higher version package.
>>
>> Where are those timestamps kept? Hint files does not contain any
>> timestamp and setup.ini only has its global timestamp, but not
>> per-package timestamps.
>>
>> Do you have any suggestion of how to fix this?
>
>
> Assuming you've found a bug, I need some more details to enable me to
> reproduce it, before I can fix it...
>
>
>> 2017-11-29 18:52 GMT+02:00 Jon Turney:
>>>
>>> On 29/11/2017 15:06, Ivan Gagis wrote:
>>>>
>>>>
>>>> I have an overlay cygwin repo where I publish my packages.
>>>>
>>>> Recently I started getting errors from mksetupini script:
>>>>
>>>> "
>>>> mksetupini: package 'mypackage' version '0.4.38-1' is most recent
>>>> non-test version, but version '0.4.43-1' is curr:
>>>> mksetupini: package set has errors, not writing setup.ini
>>>> "
>>>>
>>>> there was no such errors before. And I don't have "test:" in any hint
>>>> files of my packages, so no I dea why it thinks that some versions are
>>>> non-test and curr is test?
>>>
>>>
>>>
>>> It's not saying any versions are test.
>>>
>>>> Can you explain what this actually means?
>>>
>>>
>>>
>>> "most recent" means "latest timestamp"
>>>
>>> So this is telling you that 0.4.38-1 is the non-test version which has
>>> the
>>> most recent timestamp, but 0.4.43-1 is curr: (because it's the highest
>>> non-test version)

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: mksetupini fails validating packages because curr is test

[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:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: mksetupini fails validating packages because curr is test

[Wayne Davison]

On Thu, Nov 30, 2017 at 1:28 AM, 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.

One thing you can do after a clone/update is to run a script that
tweaks each file's mtime to be its last-commit time. I like to do this
on a fresh clone so that the files have more accurate dates visible
when looking around the checkout. (You have to be careful to not shoot
yourself in the foot if you're using time-based building in the git
repo, but that shouldn't matter in this scenario.)  I've seen various
scripts on the web, including this one in perl:

https://download.samba.org/pub/unpacked/rsync/support/git-set-file-times

..wayne..

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: mksetupini fails validating packages because curr is test

[Ivan Gagis]

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.

Br,
Ivan

2017-11-30 14:41 GMT+02:00 Jon Turney <jon.turney@dronecode.org.uk>:
> 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:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: mksetupini fails validating packages because curr is test

[Jon Turney]

On 30/11/2017 22:16, Ivan Gagis wrote:
> Thanks for prompt actions!

No problem.

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

Ok. You can get it with:

   pip3 install git+http://cygwin.com/git/cygwin-apps/calm.git

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: mksetupini fails validating packages because curr is test

[Ivan Gagis]

Ok, thanks! But what would be the schedule of releasing it to cygwin repo?

I don't want to mess up my CI scripts which install the whole build
env from scratch on every build, so I need it in cygwin repo.

Br,
Ivan

2017-12-01 13:00 GMT+02:00 Jon Turney <jon.turney@dronecode.org.uk>:
> On 30/11/2017 22:16, Ivan Gagis wrote:
>>
>> Thanks for prompt actions!
>
>
> No problem.
>
>> I think no need to package it separately for testing, just release it
>> to cygwin repo.
>
>
> Ok. You can get it with:
>
>   pip3 install git+http://cygwin.com/git/cygwin-apps/calm.git

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: mksetupini fails validating packages because curr is test

[Jon Turney]

On 04/12/2017 12:02, Ivan Gagis wrote:
> Ok, thanks! But what would be the schedule of releasing it to cygwin repo?
> 
> I don't want to mess up my CI scripts which install the whole build
> env from scratch on every build, so I need it in cygwin repo.

So, you do want me to package it!

I uploaded calm-20171204-1

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: mksetupini fails validating packages because curr is test

[Ivan Gagis]

Exactly! Thanks, it works perfectly now!

Br,
Ivan

2017-12-04 16:00 GMT+02:00 Jon Turney <jon.turney@dronecode.org.uk>:
> On 04/12/2017 12:02, Ivan Gagis wrote:
>>
>> Ok, thanks! But what would be the schedule of releasing it to cygwin repo?
>>
>> I don't want to mess up my CI scripts which install the whole build
>> env from scratch on every build, so I need it in cygwin repo.
>
>
> So, you do want me to package it!
>
> I uploaded calm-20171204-1

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple