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

Reply via email to