Bug 220717 - net-p2p/libtorrent-rasterbar: fails to build with boost 1.65 (7 ports skipped)
Summary: net-p2p/libtorrent-rasterbar: fails to build with boost 1.65 (7 ports skipped)
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Jan Beich
URL: https://github.com/boostorg/config/co...
Keywords: needs-patch
Depends on:
Blocks: 220714
  Show dependency treegraph
 
Reported: 2017-07-13 23:28 UTC by Jan Beich
Modified: 2017-09-08 06:38 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer 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 freebsd_committer 2017-09-07 23:07:23 UTC
Feedback timeout: maintainer failed to contact upstream.
Comment 2 commit-hook freebsd_committer 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 freebsd_committer 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 freebsd_committer 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.