Request for assistance closing some old pull requests

[Perry E. Metzger]

On Mon, 19 Mar 2018 17:10:52 +0100 Mojca Miklavec
<mojca at macports.org> wrote:
> On 19 March 2018 at 16:44, Perry E. Metzger wrote:
> >
> > 1: wine*: add 64-bit support
> >    https://github.com/macports/macports-ports/pull/442
> >    Apr 22, 2017 (yes, almost a year old)
> >
> > This PR seems to be stuck on the fact that Wine de facto needs a
> > 64 bit version to be useful in a modern context, but that macOS
> > is likely permanently ABI incompatible with Wine 64.
> >
> > My proposal here is that we close the PR, and that we remove the
> > Wine port as being unmaintainable going forward.  
> 
> I strongly oppose the idea of removing Wine since that's a wonderful
> tool, and Ryan maintains it on regular basis. Or at least we should
> not remove it as long as it can be compiled and used, even if in
> 32-bit mode.

That's fine.

> 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.

There's no good way to shim the ABI without having something
physically deal with this problem, which likely requires a lot of
work on very low level hacking. This might be feasible, but it is not
ready for a Pull Request.

> > 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?)

Perry
-- 
Perry E. Metzger		pmetzger at macports.org