The premature push of 0.1j included files generated by repyhelper (as shown in #518). These *_repy.py files, because they get regenerated and thus modified on the client, appear to be new updates every time the software updater checks for updates. As a result, they are downloaded by the software updater and the nodemanager is restarted because files have changed.
This update check and restart would normally happen about every half an hour. However, the /home/couvb/public_html/updatesite/0.1 directory on seattle.cs had already been renamed, preventing updates from non-updated clients until the prematurely pushed 0.1j is fully triaged. Thus, this is not affecting current clients, whether updated or not.
If 0.1j is fine and decided to be again made available for update to, the current metainfo that lists the *_repy.py files would need to be recreated to exclude these files. The better solution may be to consider this incentive for going straight to a 0.1k release once #518 is fixed.
The premature push of 0.1j included files generated by repyhelper (as shown in #518). These *_repy.py files, because they get regenerated and thus modified on the client, appear to be new updates every time the software updater checks for updates. As a result, they are downloaded by the software updater and the nodemanager is restarted because files have changed.
This update check and restart would normally happen about every half an hour. However, the /home/couvb/public_html/updatesite/0.1 directory on seattle.cs had already been renamed, preventing updates from non-updated clients until the prematurely pushed 0.1j is fully triaged. Thus, this is not affecting current clients, whether updated or not.
If 0.1j is fine and decided to be again made available for update to, the current metainfo that lists the *_repy.py files would need to be recreated to exclude these files. The better solution may be to consider this incentive for going straight to a 0.1k release once #518 is fixed.