[haiku-development] Re: HaikuPorter Buildmaster is busted (again)
- From: Michael Lotz <mmlr@xxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 15 Oct 2017 16:03:21 +0200
On 15.10.2017 12:53, waddlesplash wrote:
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.
As I said, I will look into this today and implement fixes for both issues.
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?
Because I set up a new x86_gcc2 builder as a VM alongside the x86_64 one
on Thursday. This was the one that eventually ran out of space which
caused some strange behaviour like timeouts on the SSH connections.
Would it be possible to request an "everything" build, so these
packages can be built without having their revisions arbitrarily
bumped?
Sure, building a list of ports to be built from the list of all
packages, minus the existing ones should be relatively easy. The
mechanism exists in HaikuPorter, but it doesn't output the right part of
the information right now. I can look into adding the relevant bits
(canonical package names) and add a way to translate between package
names and port names. The buildmaster code does both, so it's only a
matter of exposing it externally.
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.
That's not how I understood it would work. The mechanism of jam
upload-packages also ensures that the referenced packages actually
exist, which seems convenient and important to me. Does the new
mechanism ensure the same?
IMO the old mechanism should just stay the way it is. The packages can
certainly still be built normally through HaikuPorts and automated
package building, just that a core developer explicitly approves the
outcome by uploading them via jam.
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.
It was a current nightly as of Thursday, hrev51468 to be exact. It
includes both of the reverts, but it was unable to keep the connection
stable for anything past a couple of MiBs. The setup uses a reverse
tunnel to expose the internal SSH server to vmpkg, so everything
essentially goes through a single TCP connection. This worked fine for
the x86_64 VM since I set it up at the end of July. The x86_64 VM is at
hrev51312 and doesn't include any of the patches. The original x86_gcc2
builder (which is now used again) is at hrev51321, again with the same
reverse tunnel and without the TCP patches, and also worked reliably
since the end of July apart from the KDL this week.
Regards,
Michael
Other related posts:
