On Tue, 1 Sep 2020 at 03:41, Dewey Garrett <dgarr...@panix.com> wrote:
> The 'Address already in use' probably relates to an earlier problem and > likely needs manual intervention or a reboot of the reporting buildbot > instance(s). A reboot will (conventionally) rm the LOCKFILE in /tmp > as well. This is getting confusing. Looking at the grid view (which has not been updating properly, but is a bit easier to see than the waterfall) 139a46cec79f... in qtvcp_py3 got stuck in the well-known way Waiting for component 'inihal' to become ready............................................................................. So I terminated it from the IRC interface. Then a 2.8 build, one commit after the 2.8 tag ( 69f7ce09bcf8... in 2.8 ) ran, and actually went OK, though one of the deb builds failed due to being out of disk space http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/4509 Then your 2.8 + patch branch ( 80b413852a1d... in dgarr/tst28 ) was built, and the problem was back, with runtests failing As i write this the deb building part of 69f7ce09bcf8... in 2.8 is building debs, but looking a the logs of some completed deb builds it looks like the the upload to the release folder is not happening, presumably because the current 2.8 HEAD isn't a release tag. I have no idea how to recover this situation. I could delete the tag, but would that make things worse? -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
