[haiku-development] Re: Package buildbots

  • From: Jessica Hamilton <jessica.l.hamilton@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 18 Oct 2016 08:13:33 +0000

On Tue, 18 Oct 2016 8:57 pm Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>
wrote:

18 octobre 2016 09:39 "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> a écrit:
Am 15/10/2016 um 10:59 schrieb Adrien Destugues:

I'm now at a point where the setup works reasonably well. It's time to
start plugging actual buildbots to it (so far I have used my two
development machines).

Great news!

The release branch with the recipes used:
https://github.com/pulkomandy/haikuports/tree/release
(I will push this to the haikuports repo if the haikuports team is ok
with that)

Well, that's where it ultimately belongs, doesn't it?

We will need policies on who can push to that branch and what the process
is. Since the build of package repos will ultimately be triggered by
pushing to that branch, we need to be reasonably sure that we don't push
too broken things there.


Personally, I believe we need a split. Core packages that are essential for
Haiku itself should be under the Haiku umbrella of hosting, and then apps
and whatnot under Haikuports.

And ideally, there should be mechanisms for third party repositories,
haikuports included, to resolve dependencies to other repositories. This
would also make automating builds for third party repositories easier when
dependencies belong to others, and package versions change, etc.

But that's likely a lot of work, and shouldn't delay work on a release.

I'd be keen on a fork under Haiku and cherry picking commits. Even if we
have automated builds, don't we still need committers to the haiku tree to
publish changes anyway?

Currently this is implemented by me reviewing the recipes, since I'm the
only one with push access to my fork. But if we move things to haikuports
in the same repo as the main branch, all haikuports people will be allowed
to push to it. I think that's ok but we need to set some rules there, and
see how to make it possible to implement them. Maybe we need a
"testing/staging" branch.

If the Haiku project is fine with leaving this in control of the
HaikuPorts project, I'll move the discussion there. Otherwise, we could put
that branch on Haiku's github repos instead and keep some control on it.

Also, this morning I've set up a first bot, provided by Arfonzo. It's
currently (slowly) running over the current package list.

From the previous builds I remember some issues we will need to fix:
- gcc_6809 is broken. I suggest removing it from the depot since I'm
likely the only user. I'll fix the recipe later.
- avr_gcc is also broken. It would be nice to fix this one as it is used
for Arduino.
- there is a mismatch between mesa_x86 and llvm_x86. I suggest downgrading
llvm to fix mesa build, or updating mesa to match the current llvm version.
Possibly the llvm libs need a version prefix.

On the TODO list is also making more improvements to the build status
page, and moving some of the logic server-side (the current page downloads
several megabytes of JSON and process it in javascript on user side, it is
slow and bulky). We may be able to reuse some of Kallisti5 and
waddlesplash's work here, and maybe put some GCI students on the job.

--
Adrien.


Other related posts: