In file included from mpi.cpp:4:
In file included from ../include/libtorrent/tommath_private.h:18:
In file included from ../include/libtorrent/tommath.h:22:
../include/libtorrent/export.hpp:37:12: fatal error: 'boost/config/select_compiler_config.hpp' file not found
# include <boost/config/select_compiler_config.hpp>
1 error generated.
Feedback timeout: maintainer failed to contact upstream.
A commit references this bug:
Date: Thu Sep 7 23:07:35 UTC 2017
New revision: 449431
net-p2p/libtorrent-rasterbar: unbreak with boost 1.65
Obtained from: upstream
Approved by: portmgr blanket
(In reply to Jan Beich from comment #1)
Claiming there is a timeout here is absurd! When this ticket was opened, Boost 1.65 was in beta, so after getting clarification that the beta was not going to be committed to ports, I've been waiting for 1.65 to be released and land in ports so I could then update this port. Boost 1.65.0 was released a couple weeks ago and 1.65.1 just yesterday but neither are in the ports tree yet so there cannot be a timeout for related ports. I was certainly not about to rush to add a patch for something not yet ready given upstream could release a new version with that change incorporated before you got around to getting Boost 1.65.x into ports. How about you communicate your intentions and finish your own work before messing with other people's ports?
(In reply to Matthew Rezny from comment #3)
> When this ticket was opened, Boost 1.65 was in beta
Did you contact upstream? It's your job as the maintainer. Before reporting I've obviously checked the issue wasn't a regression in Boost itself.
> so after getting clarification that the beta was not going to
> be committed to ports,
Beta - not. Release - yes. Bug 220714 comment 1 stated there could be mass-BROKEN per timeouts. Unfortunately, users often blame committers rather than maintainers when such regressions happen or propose maintenance nightmare (e.g., several boost versions in ports).
> I've been waiting for 1.65 to be released and land in ports so I could
> then update this port.
Did you forget to communicate the intent in the bug? Double standard?
> Boost 1.65.0 was released a couple weeks ago
But enough for maintainer timeout.
> and 1.65.1 just yesterday
Irrelevant. Bug 220714 didn't land during 1.65.0 timeframe because another exp-run was required. exp-run? flag and Assignee were set, so I thought Summary bump was enough of a trigger but it appears not.
> add a patch for something not yet ready
Does upstream actually test on FreeBSD? If not you can't rely on upstream QA and have to manage risk of backports independently. In other words, "ready" is defined by downstream maintainer which failed to respond in time.
> given upstream could release a new version
Did you ask upstream? Waiting silently would mean you don't care this port may end up BROKEN.
> How about you communicate your intentions ... ?
Not sure what you have trouble picking up from bugzilla. The intent is clear: land bug 220714 while tracking fallout. Unfortunately, exp-run paints an incomplete picture due to some ports (e.g. this one) blocking other Boost consumers.
> ... and finish your own work ...?
Did you miss it was done since bug 220714 comment 1 ? ;) powerpc* issue wasn't a blocking one because the arch isn't Tier1.
> before messing with other people's ports
Boost updates are hard exactly because there're often a lot of work in consumers. Ideally, maintainers help by offering fixes to spare a committer from poor quality ones.