|Summary:||net-p2p/libtorrent-rasterbar: fails to build with boost 1.65 (7 ports skipped)|
|Product:||Ports & Packages||Reporter:||Jan Beich <jbeich>|
|Component:||Individual Port(s)||Assignee:||Jan Beich <jbeich>|
|Severity:||Affects Only Me||CC:||rezny|
|Bug Depends on:|
Description Jan Beich 2017-07-13 23:28:07 UTC
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. http://sprunge.us/UiXf
Comment 1 Jan Beich 2017-09-07 23:07:23 UTC
Feedback timeout: maintainer failed to contact upstream.
Comment 2 commit-hook 2017-09-07 23:08:42 UTC
A commit references this bug: Author: jbeich Date: Thu Sep 7 23:07:35 UTC 2017 New revision: 449431 URL: https://svnweb.freebsd.org/changeset/ports/449431 Log: net-p2p/libtorrent-rasterbar: unbreak with boost 1.65 PR: 220717 Obtained from: upstream Approved by: portmgr blanket Changes: head/net-p2p/libtorrent-rasterbar/Makefile head/net-p2p/libtorrent-rasterbar/distinfo
Comment 3 Matthew Rezny 2017-09-08 03:54:09 UTC
(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?
Comment 4 Jan Beich 2017-09-08 06:38:43 UTC
(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.