you talk about this stuff when there isn't even a native word processer
who would want to use this os
On 10/5/17 5:45 PM, Michael Lotz wrote:
On 30.09.2017 16:13, Adrien Destugues wrote:
However, this means packages doing notifications are now broken. I tried
to trigger a rebuild of the Vision package by bumping its REVISION,
however, it seems the package build bots and builmaster are still using
an old version of Haiku, so Vision was still built against the old ABI
and the new package still crashes on an up to date system.
Yes, the update process of the buildmaster is one of the items that I started a discussion about that never concluded.
The simplest is to regularly update everything (builders and buildmaster). With buildmaster the version of Haiku running on the builder is somewhat independent of the version packages are built against (as long as they are syscall compatible). The buildmaster distributes the Haiku packages to the builders to be used in the chroot the same way it does for other dependencies. Still, having them diverge too much probably isn't a good idea.
What is the process to update the haiku packages on buildmaster? Do I
just ssh to there and drop newer haiku packages at the right place?
Yes, that would be the manual option. The place in this case would be the initial-packages directories of the respective buildmaster instance:
/builds/buildmaster/master/x86_[gcc2|64]/haikuports/buildmaster/initial-packages
Any updated initial dependency packages should be updated there as well.
Should we automate that from the nightly builds of Haiku or something?
Possibly. The problem here is that all packages built after an update will require at least that Haiku version. This would force people to update their base Haiku just to get to a package that would technically be perfectly compatible with their older Haiku. This is mostly a policy decision IMO.
The buildmaster bootstrap process (not related to the Haiku bootstrap process) currently builds a haiku-nightly.image and then uses the downloaded and built HPKGs to seed its initial-packages.
An automated update process could easily reuse that mechanism, updating the cloned Haiku repository, rebuilding the image and re-seeding the initial-packages from it.
I have done the above update process manually now and updated the initial-packages for both buildmaster instances. I will add a script to HaikuPorter to automate these steps (analogous to the bootstrap script).
When to update, and how to decide what packages to rebuild as well as how to trigger the builds (rebuild everything after such an update or bump the revision of the individual recipes) is still up for debate. Depending on the update granularity rebuilding everything could be prohibitive. Seeing that the breaking changes are relatively rare, I'd consider a manually triggered approach like with the time_t change.
I'd also favour not rebuilding everything needlessly, seeing that my two builder instances are the only ones producing packages and the x86_gcc2 one has extremely slow IO.
Regards,
Michael
