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. _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
