Bug 238171 - net/frr7: Fails to configure with Python 3.7
Summary: net/frr7: Fails to configure with Python 3.7
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Olivier Cochard
Depends on:
Reported: 2019-05-27 13:41 UTC by dgilbert
Modified: 2019-06-01 01:06 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (olivier)
koobs: merge-quarterly-


Note You need to log in before you can comment on or make changes to this bug.
Description dgilbert 2019-05-27 13:41:11 UTC
One of these things is in error.  Either frr7 should build with python3.7 (Makefile says 3.6+) _or_ it shouldn't (the configure stage fails).  In support of the former, it looks like it's looking for python3-config ... so maybe it means it should depend in some way that forces python3 to install after python37?  I have python37 as default version in my make.conf for this build.

An excerpt from the Makefile:

USES=           autoreconf bison compiler:c++11-lang gmake pkgconfig libtool \
                makeinfo python:3.6+,build readline


An excerpt from the build log:

checking for python3-config... no
checking for python-config... no
checking for python2-config... no
checking for python3.6-config... no
checking for python3.5-config... no
checking for python3.4-config... no
checking for python3.3-config... no
checking for python3.2-config... no
checking for python2.7-config... no
checking for PYTHON (python-3.6)... no
checking for PYTHON (python-3.5)... no
checking for PYTHON (python-3.4)... no
checking for PYTHON (python-3.3)... no
checking for PYTHON (python-3.2)... no
checking for PYTHON (python-2.7)... no
configure: error: in `/wrkdirs/usr/ports/net/frr7/work/frr-frr-7.0':
configure: error: could not find python-config or pkg-config python, please install Python development files from libpython-dev or similar
See `config.log' for more details
===>  Script "configure" failed unexpectedly.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2019-05-27 13:51:17 UTC
Thanks for the report. Could you include the following (as attachments) please:

- The full build log
- WRKSRC/config.log

It appears that ffr supports Python 2.7 to 3.6 currently (based on the versions it appears to be enumerating in configure, and upstream code [1]). Why the port is limited to 3.6+ only I don't know, but based on evidence this should be USES=python:2.7-3.6.

See Also: https://github.com/FRRouting/frr/pull/3986

[1] https://github.com/FRRouting/frr/commit/0fca9cee3641a1e75f9d56a8ad8f5ce8bc824d93
Comment 2 dgilbert 2019-05-27 14:10:18 UTC
build log:


as for config.conf ... how do I cause poudriere to keep that?
Comment 3 dgilbert 2019-05-27 14:12:19 UTC
(In reply to Kubilay Kocak from comment #1)
except for the fact that it checks for python3-config ... which is failing because poudriere doesn't pull in lang/python-3?
Comment 4 Kubilay Kocak freebsd_committer freebsd_triage 2019-05-27 14:22:57 UTC
(In reply to dgilbert from comment #2)

Please include any requested logs as attachments, as external URL references tend to go stale/missing over time.

For config.log, use 'testport -i' to enter the build jail and grab the log
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2019-05-27 14:28:54 UTC
(In reply to Kubilay Kocak from comment #4)

It is looking for those in addition to pythonX.Y-config variants, as different OS's package python in different ways.

The issue is that while ffr7 may well support 3.7 'in practice', their configure.ac doesn't currently look for it to satisfy the dependency, which is why it's failing.

The second contributing cause is you set 3.7 as your default versions, and the third contributing cause is the port sets USES=python3.6+

The third, implies that your second, is OK, which is incorrect (configure says otherwise).

The PR I referenced in comment 1 was an example showing 3.7 being added. The PR is still open, but does not include updating python*-config elements of configure.ac

Right now, the fix is to set the port to declare *correctly* what versions this software supports, which is 2.7-3.6

The longer term goal (for you), is to get upstream to add support for Python 3.7, so that you don't need a different (and multiple) versions of Python installed on your system.
Comment 6 commit-hook freebsd_committer 2019-05-28 16:39:59 UTC
A commit references this bug:

Author: olivier
Date: Tue May 28 16:39:37 UTC 2019
New revision: 502902
URL: https://svnweb.freebsd.org/changeset/ports/502902

  Restrict python versions used to build net/frr7

  PR:		238171
  Submitted by:	koobs
  Reported by:	dgilbert@eicat.ca

Comment 7 Olivier Cochard freebsd_committer 2019-05-28 16:45:07 UTC
Thanks David for the report and thanks koob for spotting the bug in the Makefile.
Comment 8 Kubilay Kocak freebsd_committer freebsd_triage 2019-05-29 03:03:43 UTC
Thanks Olivier. Could you MFH this to quarterly please (that version is affected)

Happy to do it if you don't want to
Comment 9 Olivier Cochard freebsd_committer 2019-05-29 06:35:47 UTC
(In reply to Kubilay Kocak from comment #8)

Yes can you MFH it please ?

I didn't reach to do it myself:

/usr/ports/Tools/scripts/mfh r50290
svn: E165001: Commit failed (details follow):
svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output:
It seems that the mergeinfo is at the wrong place.

Comment 10 Kubilay Kocak freebsd_committer freebsd_triage 2019-05-31 12:45:55 UTC
(In reply to Olivier Cochard from comment #9)

Syntax for revision doesn't need 'r' prefix to revision number, and it looks like the revision number was truncated, "r50290" not "502902"

I'm trying the MFH now
Comment 11 Kubilay Kocak freebsd_committer freebsd_triage 2019-05-31 13:53:45 UTC
(In reply to Kubilay Kocak from comment #10)

Experiencing the same issue as you. Have emailed ports-secteam CC you
Comment 12 Antoine Brodin freebsd_committer 2019-05-31 14:03:31 UTC
There is no net/frr7 in 2019Q2,  why do you want to merge?
Comment 13 Kubilay Kocak freebsd_committer freebsd_triage 2019-06-01 01:06:17 UTC
(In reply to Antoine Brodin from comment #12)

Ugh, didn't even occur to me to check. Thanks Antoine