Volunteer for a workshop on "setting up your own buildbot/buildslave"?

[Ryan Schmidt]

On Nov 10, 2015, at 4:31 AM, Mojca Miklavec wrote:

> Hi,
> 
> On Mon, Nov 9, 2015 at 10:29 PM, Ryan Schmidt wrote:
>> On Nov 9, 2015, at 2:34 AM, Artur Szostak wrote:
>> 
>>> Let me ask another question: Is there a seamless way to add building and mirroring services from 3rd parties for the pre-built binaries?
>> 
>> No. We want verified binaries built in a clean-room by known servers, not binaries built in unknown conditions by arbitrary contributors.
> 
> But from what I understand one should be able to *manually* add a
> buildbot's IP or URL to fetch the binaries? I totally agree that
> MacPorts should not support adding arbitrary buildbots automatically,
> but it should be possible to add your own, right?
> 
> Me and Aljaž were discussing the idea of:
> - bringing a recent decent mac to the MacPorts meeting (in March 2016)
> - bringing a PowerMac G5
> - trying to set up a local mirror (for distfiles etc.) and a local
> buildbot/buildslave on both
> - preparing a short workshop/tutorial about setting up your own
> buildbot/buildslave (with someone preparing slides with clear
> instructions and giving enough time for a hands-on exercise)
> 
> The output/benefit of this workshop would be the following:
> - having a 10.5 buildslave (ideally also including libc++ support) at
> hand to get feedback about potential problems with software (and
> hopefully having an unofficial 10.11 buildslave to play with)
> - get more developers familiar with the process
> - so that potentially some university/company could easily set up
> their own buildbots according to their local needs, or maybe just to
> build some additional software that is not part of the official
> distribution
> - so that a group of "hackers" with mutual trust could use their own buildbots
> - so that a group of developers could decide to easily test some
> nontrivial changes in private trees with portfiles (like a switch from
> multiple versions of Perl to a single version; or a move of Qt from
> one location to another)
> - so that some eager user could monitor building problems of the
> latest commits in case the official buildbots experience problems
> 
> My question is: is there any volunteer on this list (independent on
> whether he or she will be able to physically attend the meeting) to
> prepare the workshop [materials] and test the procedures?

You could presumably edit archive_sites.tcl to add another packages server IP address. (MacPorts does not fetch from the buildbot servers directly; the buildbot servers upload to the packages server, and MacPorts fetches from that.)

I think interest in PowerPC systems is truly very low at this time. But I would like to see the ability to automatically build packages for older systems with libc++, and offer a MacPorts installer that comes preconfigured for libc++ on older systems.

But we can't have a buildbot for libc++ on older systems until MacPorts base gets a mechanism for differentiating libc++ packages from libstdc++ packages, for example with an extra string in the package filename. We've brought this up before. There are many variables that go into a package: name, version, revision, variants, platform, platform version, and architectures currently go into the filename; archive type, prefix, frameworks dir and applications dir are currently specified in archive_sites.tcl; and other variables such as cxxstdlib, macosx_deployment_target and macosx_sdk are assumed to be at their defaults, and any users who modify those variables are expected to know to disable the use of binaries, lest they get a binary built with different values for those variables. It might be nice to have a more robust way of specifying all the relevant variables. I'm not sure what that method would be; we can't just go adding endless variables to package filenames.