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
--
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
