Current setup timestamp 1590343308

Current setup timestamp 1590343308

[Fergus Daly]

Current setup timestamp 1590343308
does not seem to overwrite /etc/setup/timestamp accurately (or at all).
I think /etc/setup/installed.db is seen to as it should be.
Fergus

Re: Current setup timestamp 1590343308

[marco atzeri]

On Mon, May 25, 2020 at 2:08 PM Fergus Daly via Cygwin wrote:
>
> Current setup timestamp 1590343308
> does not seem to overwrite /etc/setup/timestamp accurately (or at all).
> I think /etc/setup/installed.db is seen to as it should be.
> Fergus
> --

What exactly is your problem ?
Be verbose we can NOT guess your thoughts.

Unix time: seconds since Jan 01 1970. (UTC)
https://www.unixtimestamp.com/index.php

RE: Current setup timestamp 1590343308

[Fergus Daly]

-----Original Message-----
From: marco atzeri [mailto:marco.atzeri@gmail.com] 
Sent: 25 May 2020 13:13
To: Fergus Daly
Cc: cygwin@cygwin.com
Subject: Re: Current setup timestamp 1590343308

On Mon, May 25, 2020 at 2:08 PM Fergus Daly via Cygwin wrote:
>
> Current setup timestamp 1590343308
> does not seem to overwrite /etc/setup/timestamp accurately (or at all).
> I think /etc/setup/installed.db is seen to as it should be.
> Fergus
> --

What exactly is your problem ?
Be verbose we can NOT guess your thoughts.

Unix time: seconds since Jan 01 1970. (UTC)
https://www.unixtimestamp.com/index.php

Sorry for lack of clarity.
Cygwin32.
Current installed timestamp 1590341902 (got from /etc/setup/timestamp).
I noticed there's a newer setup.ini with timestamp 1590343308.
So I ran setup-x86.exe.
After a (presumed) successful run I noticed however, that the file /etc/setup/timestamp had not altered.
"Presumed successful run" because the file /etc/setup/installed.db had a new, current, timestamp.
Fergus
(I deleted /etc/setup/timestamp and re-running setup-x86.exe to see whether any self-correcting behaviour would ensue. The file was not recovered.)

Re: Current setup timestamp 1590343308

[Brian Inglis]

On 2020-05-25 06:26, Fergus Daly via Cygwin wrote:
> On 25 May 2020 13:13, marco atzeri wrote:
>> On Mon, May 25, 2020 at 2:08 PM Fergus Daly via Cygwin wrote:

>>> Current setup timestamp 1590343308
>>> does not seem to overwrite /etc/setup/timestamp accurately (or at all).
>>> I think /etc/setup/installed.db is seen to as it should be.

>> What exactly is your problem ?
>> Be verbose we can NOT guess your thoughts.
>> 
>> Unix time: seconds since Jan 01 1970. (UTC)
>> https://www.unixtimestamp.com/index.php

> Sorry for lack of clarity.
> Cygwin32.
> Current installed timestamp 1590341902 (got from /etc/setup/timestamp).
> I noticed there's a newer setup.ini with timestamp 1590343308.
> So I ran setup-x86.exe.
> After a (presumed) successful run I noticed however, that the file
> /etc/setup/timestamp had not altered.
> "Presumed successful run" because the file /etc/setup/installed.db had a
> new, current, timestamp.

> (I deleted /etc/setup/timestamp and re-running setup-x86.exe to see whether 
> any self-correcting behaviour would ensue. The file was not recovered.)
It looks to me that /etc/setup/timestamp is updated by the last successful setup
(upgrade?) run, and contains a copy of the selected mirror's setup.ini
setup_timestamp field as of the last successful setup (upgrade?) run, a few
hours earlier than the last successful setup (upgrade?) run.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]

Re: Current setup timestamp 1590343308

[Fergus Daly]

>> Ken Brown said:
>> That option is built into my setup script .. ..

I use a setup script too and - whoops - it emerged that an assumption on which the script is based was broken.
(The -L switch to the setup executable was badly configured.)
Re-set, and all is fine.
Very sorry to have wasted readers' time and yours in particular.
Fergus

PS I always send in Plain Text.
Word Wrap always looks fine and well-managed, but sometimes (lately more often) arrives at cygwin dot com
with long lines which are inconvenient to say the least.
Is there a trick to guarantee Word Wrap arrives as intended?

Re: Current setup timestamp 1590343308

[Brian Inglis]

On 2020-05-25 14:14, Fergus Daly via Cygwin wrote:
> Fergus Daly said:
>>> What I have observed, twice now (earlier today using setup.ini incorporating timestamp 1590343308 and now using the latest setup.ini incorporating timestamp 1590407755) is that event (ii) is failing: the file /etc/setup/timestamp is not updated - and if it isn't there at all, it is not created.
> 
> Ken Brown said:
>>> I'm not seeing any change in behavior on my system.  I just deleted 
> /etc/setup/timestamp and ran setup.  A new /etc/setup/timestamp was created, 
> with contents 1590430423.  This matches the value in the downloaded setup.ini file:
>     setup-timestamp: 1590430423
> Do you see any error messages involving /etc/setup/timestamp in the setup log 
> files in /var/log?
> 
> And thank you for this. In a way I am encouraged that things remain as they should be for you and presumably for others, and that there's some kind of local glitch on my machine.
> It is trivially annoying, perplexing - and persistent! (I've just updated to 1590430423) with these consequences:
> Nothing at all relevant in /var/log/setup.log*:
> ~> grep timestamp /var/log/setup.log*
> ~>
> yields nothing. And
> ~> ls -altr /etc/setup/
> ends with
> ..
> ..
> -rw-r--r-- 1   404 May 22 09:39 perl-TimeDate.lst.gz
> -rw-r--r-- 1   629 May 22 09:39 mintty.lst.gz
> -rw-r--r-- 1    11 May 25 17:10 timestamp
> -rw-r--r-- 1 16283 May 25 20:45 installed.db
> -rw-r--r-- 1    64 May 25 20:45 setup.rc
> showing that the last update that actually altered my provision - not the full offering by any means - took place on May 22. The timestamp file at time 17:10 today is an artificial creation with the contents 1580000000 so that tracking is easy. The update to 1590430423 occurred at 20:45 today and revised only two of the three files that would normally be updated - /etc/setup/timestamp has not changed.
> .. .. ??!!
> As I say - perplexing.
> Fergus 
> (And /etc/setup/timestamp should update, even when there's no change to a user's provision. It always has, until today.)
> Thanks anyway.

Is the difference whether set-x86/_64 option "-g, --upgrade-also Upgrade
installed packages also" is specified or not?
That option is built into my setup script in case install dependencies need
upgraded, and as the default if no install is requested.
I only run setup manually to install downgrades, tests, or when version formats
change.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]

Re: Current setup timestamp 1590343308

[Brian Inglis]

On 2020-05-25 14:14, Fergus Daly via Cygwin wrote:
> Fergus Daly said:
>>> What I have observed, twice now (earlier today using setup.ini incorporating timestamp 1590343308 and now using the latest setup.ini incorporating timestamp 1590407755) is that event (ii) is failing: the file /etc/setup/timestamp is not updated - and if it isn't there at all, it is not created.
> 
> Ken Brown said:
>>> I'm not seeing any change in behavior on my system.  I just deleted 
> /etc/setup/timestamp and ran setup.  A new /etc/setup/timestamp was created, 
> with contents 1590430423.  This matches the value in the downloaded setup.ini file:
>     setup-timestamp: 1590430423
> Do you see any error messages involving /etc/setup/timestamp in the setup log 
> files in /var/log?
> 
> And thank you for this. In a way I am encouraged that things remain as they should be for you and presumably for others, and that there's some kind of local glitch on my machine.
> It is trivially annoying, perplexing - and persistent! (I've just updated to 1590430423) with these consequences:
> Nothing at all relevant in /var/log/setup.log*:
> ~> grep timestamp /var/log/setup.log*
> ~>
> yields nothing. And
> ~> ls -altr /etc/setup/
> ends with
> ..
> ..
> -rw-r--r-- 1   404 May 22 09:39 perl-TimeDate.lst.gz
> -rw-r--r-- 1   629 May 22 09:39 mintty.lst.gz
> -rw-r--r-- 1    11 May 25 17:10 timestamp
> -rw-r--r-- 1 16283 May 25 20:45 installed.db
> -rw-r--r-- 1    64 May 25 20:45 setup.rc
> showing that the last update that actually altered my provision - not the full offering by any means - took place on May 22. The timestamp file at time 17:10 today is an artificial creation with the contents 1580000000 so that tracking is easy. The update to 1590430423 occurred at 20:45 today and revised only two of the three files that would normally be updated - /etc/setup/timestamp has not changed.
> .. .. ??!!
> As I say - perplexing.
> Fergus 
> (And /etc/setup/timestamp should update, even when there's no change to a user's provision. It always has, until today.)
> Thanks anyway.

Is the difference whether set-x86/_64 option "-g, --upgrade-also Upgrade
installed packages also" is specified or not?
That option is built into my setup script in case install dependencies need
upgraded, and as the default if no install is requested.
I only run setup manually to install downgrades, tests, or when version formats
change.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]

Re: Current setup timestamp 1590343308

[Ken Brown]

On 5/25/2020 12:47 PM, Fergus Daly via Cygwin wrote:
>>> It looks to me that /etc/setup/timestamp is updated by the last successful setup
>>> (upgrade?) run, and contains a copy of the selected mirror's setup.ini
>>> setup_timestamp field as of the last successful setup (upgrade?) run, a few
>>> hours earlier than the last successful setup (upgrade?) run.
> 
> Thank you for this.
> I can't really think of anything to say other than repeat my observation, today, of altered practice.
> Since as long as I can remember (and I mean - a matter of years) a successful upgrade of Cygwin32
> (implementing the current version of setup-x86.exe currently 2.904
> and pulling in the latest version of setup.ini found at {source}/Cygwin/x86/)
> has concluded with
> (i) a glitch-free accounting in /var/log/setup.log(.full), together with
> (ii) a revision of the file /etc/setup/timestamp
> which reflects the timestamp line in the aforementioned setup.ini file.
> (And other things too, quite apart from any updates to the Cygwin provision - e.g. an updated /etc/setup/installed.db file.)
> 
> What I have observed, twice now (earlier today using setup.ini incorporating timestamp 1590343308 and now using the latest setup.ini incorporating timestamp 1590407755) is that event (ii) is failing: the file /etc/setup/timestamp is not updated - and if it isn't there at all, it is not created.

I'm not seeing any change in behavior on my system.  I just deleted 
/etc/setup/timestamp and ran setup.  A new /etc/setup/timestamp was created, 
with contents 1590430423.  This matches the value in the downloaded setup.ini file:

   setup-timestamp: 1590430423

Do you see any error messages involving /etc/setup/timestamp in the setup log 
files in /var/log?

Ken

Re: Current setup timestamp 1590343308

[Fergus Daly]

>> It looks to me that /etc/setup/timestamp is updated by the last successful setup
>> (upgrade?) run, and contains a copy of the selected mirror's setup.ini
>> setup_timestamp field as of the last successful setup (upgrade?) run, a few
>> hours earlier than the last successful setup (upgrade?) run.

Thank you for this.
I can't really think of anything to say other than repeat my observation, today, of altered practice.
Since as long as I can remember (and I mean - a matter of years) a successful upgrade of Cygwin32
(implementing the current version of setup-x86.exe currently 2.904
and pulling in the latest version of setup.ini found at {source}/Cygwin/x86/)
has concluded with
(i) a glitch-free accounting in /var/log/setup.log(.full), together with
(ii) a revision of the file /etc/setup/timestamp
which reflects the timestamp line in the aforementioned setup.ini file.
(And other things too, quite apart from any updates to the Cygwin provision - e.g. an updated /etc/setup/installed.db file.)

What I have observed, twice now (earlier today using setup.ini incorporating timestamp 1590343308 and now using the latest setup.ini incorporating timestamp 1590407755) is that event (ii) is failing: the file /etc/setup/timestamp is not updated - and if it isn't there at all, it is not created.

Maybe this does not matter. The file is not referred to during any upgrade session  (or not obviously - I think the contents of /etc/setup/installed.db are what dictate any necessary upgrades to an individual user's Cygwin provision) but it has been, for me at least, a useful rapid check of whether "what I've got" matches "what is now available". 

All I was trying to do was draw attention to (what I perceive to be) suddenly altered practice, with no change to the setup executable that might have explained it or caused it. So (a) is it a real change? (easily confirmed, or not, by anybody with /etc/setup/timestamp reporting < 1590407755 then running an upgrade, and seeing what happens to /etc/setup/timestamp); and (b) if so, is it intended? or is it a trivial glitch introduced goodness-knows-how that can be corrected; and (c) if intended, to provide what improvement? because it seems to me a bad move.

Fergus