Request for assistance closing some old pull requests

[Rainer Müller]

On 2018-03-19 18:03, Perry E. Metzger wrote:
> On Mon, 19 Mar 2018 17:10:52 +0100 Mojca Miklavec
>> Last time I checked this PR was not entirely complete and from my
>> understanding that was the only reason why it was not merged. We
>> certainly need a solution for 64-bit wine in some not-too-distant
>> future; whether an incomplete patch helps with that, I don't know.
>> We should certainly keep at least a ticket on Trac with a reference
>> to the code.
> 
> So my understanding (and I might be mangling it) is that the issue
> here is that there are two x86_64 registers that are reasonable
> candidates for pointing at thread local data, and Windows has picked
> a different one from macOS. The result of this is that a register
> that Windows programs expect will be preserved gets destroyed in the
> course of calling in to the rest of the OS.

I have no idea how they solved it, but upstream claims that 64-bit is
supported on macOS.

I added more comments and commits to the PR:
https://github.com/macports/macports-ports/pull/442

>>> 2: mosh: Switch to protobuf3-cpp
>>>    https://github.com/macports/macports-ports/pull/690
>>>    Aug 17, 2017
>>>
>>> Zero King correctly notes in the course of the PR's comment thread
>>> that protobuf3-cpp conflicts with protobuf-cpp, so all
>>> protobuf-cpp using ports probably should be migrated.
>>>
>>> This seems entirely straightforward to do (I made the needed
>>> changes in my own git repo in a couple of minutes) but rather
>>> difficult to test. To close this out, we probably need some
>>> volunteer who is in a position to test such an update.  
>>
>> Can you please update the PR with your changes (replacing all
>> dependencies on protobuf-cpp with protobuf3-cpp) or perhaps open a
>> new one?
> 
> I could open a new one, but I'd prefer if someone had committed to
> help before I do that.
> 
>> Travis certainly won't be able to build them all, but the
>> list of ports to test seems reasonable. Either someone can run
>> destroot, or we can simply submit the builds to the buildbot and be
>> ready to quickly patch the failing builds.
> 
> So lets say that I submit a PR, do you think you would be in a
> position to help watch the buildbot (or do a test run?)

Unfortunately, we have no support to run builds from pull requests or
custom branches on the buildbot, as it would immediately publish the
resulting archives.

This sounds like a nice enhancement for our buildbot, though. On a
forced build, we can already specify a branch name. If buildbot would
only try to publish binary archives when running for the master branch,
we could use it to test changes like this.

Rainer