Exactly! Thanks, it works perfectly now!
Br,
Ivan
2017-12-04 16:00 GMT+02:00 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
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
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 :
> On 30/11/2017 22:16, Ivan Gagis wrote:
>
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://cygwi
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 unnece
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 tim
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
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? Is
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 tho
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 s
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
11 matches
Mail list logo
