[Bug 226883] lang/python27, lang/python35, lang/python36: libressl 2.7 build failures

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226883

Kubilay Kocak <koobs at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brnrd at freebsd.org,
                   |                            |python at FreeBSD.org
             Status|New                         |Open

--- Comment #2 from Kubilay Kocak <koobs at FreeBSD.org> ---
Thank you for your report Charlie,

Could you confirm/clarify some points that might be slightly ambiguous:

- Is D14837 the same as the OpenBSD patches, or different, fixing "both
ssl=openssl and ssl=openssl-devel" build failures referenced in comment 0?

- In D14837, Does "Fails otherwise" mean the same as "breaks both ssl=openssl
and ssl=openssl-devel" as referenced in comment 0 here, or some other
subset/combination?

- I interpreted 'upstream' in 'upstream will not release their patch' to mean
Python (waiting for libressl upstream to 'release' before committing code). Is
this correct?

An explicit/accurate/complete list of what succeeds/fails would be super handy
to figure out where/what needs work from here:

>From the standpoint of Python (team) and python ports, we'd ideally like to
take changesets from upstream after they're committed and backported there.
We're happy to carry local patches prior to next point releases in each branch.

If we can confidently get to the point where we have a candidate changeset with
thorough QA passing and no regressions, we can consider landing it early
(before upstream (Python)).

For clarity purposes, if the changeset in D14837 is incomplete (in that it
regresses certain ssl combinations), then it should be abandoned in favour of a
'work in progress' patch here for someone (Bernard, CC'd, is the point on
libressl things) to review and improve upon.

At the point where a QA passing/complete patch is ready, we can put it back up
on Phabricator for broader review, if necessary beyond here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.