Bug 196475
| Summary: | [New Port] net-p2p/libtorrent-rasterbar1 - C++ library implementing a BitTorrent client | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Cory Dohm <cadatoiva> | ||||
| Component: | Individual Port(s) | Assignee: | freebsd-ports-bugs (Nobody) <ports-bugs> | ||||
| Status: | Closed Overcome By Events | ||||||
| Severity: | Affects Only Me | CC: | cadatoiva, rm | ||||
| Priority: | --- | ||||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Bump in case the bugzilla issue caused this PR to be lost in the storm. Thanks for taking the time to look at it. Hello. Adding of new ports without maintainer is not allowed (per Porters Handbook). Would you become maintainer of those ports? And one more question, isn't libtorrent-rasterbar 1.0.3 should be linked against libtorrent 1.0.3? And if yes, then I don't see the port for libtorrent 1.0.3 itself. Would you provide it too? (In reply to Ruslan Makhmatkhanov from comment #2) Yes, I would be able to be the maintainer for these ports. No, libtorrent-rasterbar does not need to be linked against libtorrent. Update to 1.0.4 had committed in r389250 (PR 200108), while this patch wasn't commit-ready anyway. Sorry, I can't recall the details, was quite busy at $work those days to investigate/fix that. |
Created attachment 151313 [details] .shar for libtorrent-rasterbar-1.0.3 and python bindings slave port qBittorrent is incompatible with libtorrent-rasterbar 1.x but Deluge is compatible and benefits from the many bug fixes implemented in the latest stable versions. This new port is a fork of the existing libtorrent-rasterbar (and libtorrent-rasterbar-python) port updated to the latest release. I'm still new to ports maintenance, so there might be some issues.