[haiku-development] Re: HaikuPorter Buildmaster is busted (again)

  • From: waddlesplash <waddlesplash@xxxxxxxxx>
  • To: Haiku Development ML <haiku-development@xxxxxxxxxxxxx>
  • Date: Sun, 15 Oct 2017 12:53:11 +0200

On Sun, Oct 15, 2017 at 10:12 AM, Michael Lotz <mmlr@xxxxxxxx> wrote:

For one, the buildmaster package downloads currently take place directly
into the packages directory. This causes periods of times when incomplete
packages are present that can't be parsed. The second issue then is that
HaikuPorter aborts the dependency resolution when it encounters such
packages.

Yes, I encountered this yesterday, and deleted the packages that were
incomplete, which got me further at least.

You can't start manual builds while the buildmaster instance is running in
update mode, as you'd eventually get multiple instances running at the same
time. If you must run things manually (which usually shouldn't be needed),
you should stop the buildmaster@x86_[gcc2|64] instance via systemctl.

Ah, OK.

If the GCC2 builder was really KDLed, then why did builderctl show it
as being online then? Are there multiple builderctls and I used the
wrong one somehow?

Since the buildmaster instances run in update mode and they started at a
random moment in time and have only built ports affected by HaikuPorts
commits since then, not everything has been built, because not everything
has been touched since then. The remaining ports can be bumped or built
manually as needed however. I see that you already made a list in the issue
tracker.

Would it be possible to request an "everything" build, so these
packages can be built without having their revisions arbitrarily
bumped?

As agreed when the plan to switch repos was formed, the immediate Haiku
dependencies should remain with the old process of the in-tree committed
package list. This is to ensure that consistent images can be built and that
there is more control over these critical packages. I therefore don't really
know why you're now trying to switch these to the new package repos at all.

The in-tree package list will remain, but the goal was to use the
packages generated by the buildmaster. So a list of specific package
names+versions+revisions will be in the tree, and jam will download
these to do the build -- and these packages will be downloaded from
the new repos.

The initial problem was that the x86_gcc2 builder KDLed. Since I was out of
town for 3 more days at that point (which I announced on IRC), the only
thing I could do remotely was to set up a new x86_gcc2 builder along the
x86_64 one inside a VM. This VM was using a current hrev, which apparently
has very unstable networking in the exact same VM setup as compared to the
x86_64 version that is running an hrev before the recent network changes.
This will have to be investigated separately.

I'd recommend updating the GCC2 builder; two of the TCP commits were
reverted (one by me which was causing upload stalls after 500KB or so,
and one by korli which was causing some sort of other upload problem
for him) and there has been a massive stability increase after that.


Oh come on. The HaikuPorter bugs, of which one is part of the buildmaster
code, are an issue here, yes. But all the other issues are Haiku stability,
network or external factors that no solution would be impervious to.

I couldn't even tell if the GCC2 builder was actually online, though.
Builderctl seemed to indicate it was, then haikuporter couldn't
connect to it.

I am also actively maintaining the buildmaster instances, even from my only
vacation of 5 days this year. But there's only so much that can be done
remotely when you have a KDLed builder at home. I really did everything I
could, so such comments are just plain insulting.

Fair enough. Sorry for the disparaging comment; it's just that it's
rather frustrating to be so close and yet so far from being able to
switch permanently...

-waddlesplash

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 10-2017