<dol-sen>
p12tic, has anything changed with the way you package new releases? buildbot-pkg in this last release came up with a date version causing that setuptools error I reported a few days ago.
<dol-sen>
What is really strange is that this is the first time setuptools has spit out a warning like that.
<dol-sen>
It wasn't due to our eclass (install script).
<dol-sen>
So seems I'll need to export BUILDBOT_VERSION in our ebuild to avoid it.
<dol-sen>
damn, even older releases are getting setuptools warnings
<dol-sen>
even with setuptools-56.0.0
<dol-sen>
exporting BUILDBOT_VERSION fixes it
<tardyp>
the vesion works only if we build from git, or if the VERSION file is kept in the source dist
Cheyenne has joined #buildbot
<Cheyenne>
Any suggestions on how to handle a stalled worker? (e.g. have a failover worker)
<Cheyenne>
some background -- We use buildbot to perform a build validation across several platforms, once all the builds have finished a report is submitted to gerrit.
<Cheyenne>
the workers are distributed and are maintained by various people (opensource project). If one of the workers happens to be down, it holds up the build report that is submitted to gerrit
<dol-sen>
Cheyenne, maybe create another builder on a timer that just checks workers
<dol-sen>
if one is offline, have it set something that causes the main builder to timeout and send what it has
<Cheyenne>
Is it possible to have a failover builder?
<dol-sen>
I believe so, yeah
<dol-sen>
you can have many workers set for a specific builder
<dol-sen>
if one is busy/offline, it'll go to the next
<Cheyenne>
okay.. that might work. I can have a "stalled" worker that is assigned to all of the builders
<Cheyenne>
and have it "sit behind" the primary worker for that particular builder
<dol-sen>
not sure if that is correct. eg: have several arm system workers set for the arm builder, it'll use whichever is available from the list
<Cheyenne>
so there is no priority on the workers?