ping this ?

Rebase, add SC2223, remove SC2086 (to be done last).

Switching LLVM's Python should probably be discussed with LLVM's maintainer, and not here. It has nothing to do with switching the default version of Python.

I wonder if the .if FLAVOR should not be changed to checks on PYTHON_VER, so that people who change the default Python version get the correct behavior.

If it is only the build being fixed, why bump PORTREVISION?

Why do you remove all the Created by lines, were those removal requested?

In D18573#397771, @dbaio wrote:

In D18573#397762, @mat wrote:

Looks ok now. Do tell me that the USES will be used by more than three ports.

There will be about 90 ports using this USES.

Looks ok now. Do tell me that the USES will be used by more than three ports.

Rebase.

Maybe it is my english not being correct, but I thought "I would rather" meant something that would be nice but not required.

In D16457#396393, @rene wrote:

I suggest to wait for 2019Q1, then:

• update proudriere(-devel) with @mat 's patch
• update user/developer documentation
• rebase the patch
• commit the patch
• send out some emails to announce subpackages

If having an invalid value in LICENSE_FILE does not make your test builds fails, you may have DISABLE_LICENSES set somewhere.

Well, you should not use Phabricator as a place to dump the patches you are working on, use git and branches or something.

In D18451#395629, @voidanix_420blaze.it wrote:

@tobik is there any way I can get this port committed? I can't commit this yet :p

rebase.

Does this pass rclint?

• fixup! Options must use uppercase/digits.

Mmmm, ok, but outside of BROKEN_SSL being wrongly put there, do you have examples of ports that build with OpenSSL 1.1.1 from base but not from the port?

I'd rather you kept PORTDOCS, and the whole tree gets converted at once.

In D18449#394877, @antoine wrote:

Some ports set BROKEN_SSL=openssl111 but build fine on head.

In D18512#394567, @ehaupt wrote:

In D18512#394564, @mat wrote:

Absolutely not.

There is a default *SSL, no port should ever forcefully install another.

See, that's exactly why I wrote "constructive" in my initial request. Could you please at least provide an example?

Absolutely not.

You are trying to coerce flavors into doing subpackages, so it is going to be a no on flavors. You could make it an option, or a slave port.

In D18466#394013, @rigoletto wrote:

git describe --tags fcee4e0
1.4-93-gfcee4e0

The current version actually is 1.5, and IIRC it is just the TAG number that matter. Can DISTVERSION be:

1.5-93-gfcee4e0

Thanks!

Looks ok, make sure it all builds, and does not break INDEX before committing ;-)

rebase.