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

[Rainer Müller]

On 2015-11-11 14:18, Ryan Schmidt wrote:
>> You usually do not want to fetch archives for
>> anything else than the current OS,
> 
> Of course we would not want that.
> 
>> so it is implicit.
> 
> I don't know what you mean by this.

I meant there are no settings in archive_sites.tcl or
archive_sites.conf, but OS and OS release are still considered when
fetching an archive.

>> We could also host the packages in subdirectories:
>>  .../${os.platform}/${os.major}/${build_arch}/*.tbz2
>> However, you would have to replicate this structure on fetch. It would
>> not make much difference whether this is in the path or in the filename.
> 
> Yes, for my hypothetical scenario, I was assuming that, in the absence of the OS name and version being in the filename, it would be in a directory name.
> 
> packages.m.o/darwin_15/boost/...
> packages.m.o/darwin_10/boost/...
> packages.m.o/darwin_10-libc++/boost/...

We would then need two entries for these archive sites in
_resources/port1.0/fetch/archive_sites.tcl in the ports tree. For darwin
>= 13 the default of cxx_stdlib changed. Would we just make the
definition there switch on the OS release?

Also note that this would need to be reflected locally. Currently port
archives are stored at ${prefix}/var/macports/software/${name}/*.tbz2.
If we remove OS release from the filename, they need to go into the
corresponding subdirectories instead. This path is also stored in the
registry and would need to be replaced with a base upgrade.

> Having all of a port's packages -- for all platforms, variants and
> build options -- in a single directory is nice though because it's a
> single directory listing to look at to figure out if a particular
> binary exists. I use this all the time when deciding whether I need
> to force a buildbot build or investigate a buildbot build failure,
> and it would be less good for there to be even two directories to
> need to check, much less more than that.

I see your point here.

This could also be solved with a proper new web interface for the
PortIndex, that regularly checks which archives are available. However,
from experience with this topic, either nobody will write this or we
will fail once again to deploy it...

>> Is your intention to build all packages twice, for both libc++ and
>> libstdc++? Is that even worth the effort?
>
> Yes, my intention is that there would be additional buildbot slave
> servers set up for libc++ on each older OS version. Why wouldn't that
> be worth the effort? Are you suggesting as an alternative that we
> would immediately switch the older OS buildbot slaves over to libc++
> and no longer provide binaries for libstdc++? That would mean we
> would need an immediate plan for how to switch users from libstdc++
> to libc++. I was hoping to take this one problem at a time, not all
> problems at once.

Is there demand for archives linked against libc++? If that is high
enough, it should become our default and we would not need the archives
linked against libstdc++ anymore.

First setting up another buildbot instance with another configuration
makes sense on the way to this. But if we do not intent to switch the
default later, I do not see a need for this.

Rainer