Page MenuHomeFreeBSD

net/p5-WebService-Dropbox and net/dropbox-api-command: Update to 2.05 and 2.09 respectively
ClosedPublic

Authored by woodsb02 on Jul 31 2016, 6:21 AM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Dec 3, 7:08 AM
Unknown Object (File)
Mon, Nov 25, 12:57 AM
Unknown Object (File)
Sun, Nov 24, 5:26 AM
Unknown Object (File)
Sat, Nov 23, 6:30 PM
Unknown Object (File)
Sat, Nov 23, 8:15 AM
Unknown Object (File)
Thu, Nov 21, 11:32 AM
Unknown Object (File)
Thu, Nov 21, 10:55 AM
Unknown Object (File)
Wed, Nov 20, 10:46 AM
Subscribers
None

Details

Summary

net/p5-WebService-Dropbox: Update to 2.05
net/dropbox-api-command: Update to 2.09

This update brings support for Dropbox APIv2.
This is required since, according to dropbox, the API v1 will be
disabled on 28th June 2017:
https://blogs.dropbox.com/developers/2016/06/api-v1-deprecated/

Convert LWP option (off by default) to FURL option (on by default)
as testing has revealed that without the p5-LWP-Protocol-https pkg
installed, the following error is given even if the FURL option in enabled.
$ dropbox-api sync dropbox:/ ~/Dropbox
2016-07-31T14:09:57 [WebService::Dropbox] [ERROR] https://api.dropboxapi.com/2/files/list_folder {"path":"","recursive":true} -> [501] LWP will support https URLs if the LWP::Protocol::https module is installed.
LWP will support https URLs if the LWP::Protocol::https module is installed.

PR: 211016
Approved by: Lung-Pin Chang <changlp@cs.nctu.edu.tw> (maintainer timeout)

Test Plan

poudriere testport -i p5-WebService-Dropbox (and make test)
poudriere testport -i dropbox-api-command (and make test)

Test syncing from dropbox to my local PC with:
dropbox-api sync dropbox:/ ~/Dropbox

Test syncing from my local PC to dropbox with:
dropbox-api sync ~/Dropbox dropbox:/

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

woodsb02 retitled this revision from to net/p5-WebService-Dropbox and net/dropbox-api-command: Update to 2.05 and 2.09 respectively.
woodsb02 updated this object.
woodsb02 edited the test plan for this revision. (Show Details)
woodsb02 added reviewers: adamw, mat, koobs.

Diff updated to not take maintainership yet, as Lung-Pin still has until October 11 to respond for that.

net/dropbox-api-command/Makefile
18–19 ↗(On Diff #18914)

The patch would be shorter if you did not reorder those.

net/p5-WebService-Dropbox/Makefile
29 ↗(On Diff #18914)

If it is *instead* should not the LWP/libwww dependencies be added to a FURL_BUILD_DEPENDS_OFF ?

35–37 ↗(On Diff #18914)

Are you not missing a FURL_RUN_DEPENDS=${FURL_BUILD_DEPENDS} ?

Also, if the patch from the PR contained the maintainer change, you can keep it.

In D7377#153362, @mat wrote:

Also, if the patch from the PR contained the maintainer change, you can keep it.

Doesn't taking maintainership require either 3 months timeout, or 3 consecutive timeouts?

net/dropbox-api-command/Makefile
18–19 ↗(On Diff #18914)

Fair enough, no change for change's sake. But since I have also bumped the version of p5-WebService-Dropbox, might as well sort alphabetically while here.

woodsb02 edited edge metadata.

As per comments from mat:

  • Update FURL option description, to avoid confusion that LWP is not also required
  • Add FURL_RUN_DEPENDS=${FURL_BUILD_DEPENDS}
In D7377#153362, @mat wrote:

Also, if the patch from the PR contained the maintainer change, you can keep it.

Doesn't taking maintainership require either 3 months timeout, or 3 consecutive timeouts?

Well, for someone to reset the maintainership, it does requires 3 months or 3 timeouts, yes. In this case, the patch you submitted has the maintainer change, it is ok to commit it with the maintainer change.

(I'll try to explain it again a different way if you don't get the semantics of it :-p)

In D7377#153936, @mat wrote:

(I'll try to explain it again a different way if you don't get the semantics of it :-p)

Please do; I'm not clear on how we can change the maintainer without the consecutive timeout rule and without the maintainer's approval first.

In D7377#153941, @adamw wrote:
In D7377#153936, @mat wrote:

(I'll try to explain it again a different way if you don't get the semantics of it :-p)

Please do; I'm not clear on how we can change the maintainer without the consecutive timeout rule and without the maintainer's approval first.

Well, from my reading of https://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintainer.html:

  1. A patch from a PR is considered approved if the maintainer doesn't say anything after 14 days.
  2. A MAINTAINER line can be replaced if the maintainer doesn't answer for 3 months, or for 3 consecutive timeouts.

From my point of view, it doesn't preclude changing the MAINTAINER line in 1 if it is part of the patch.

The second line is there so that we don't get stuck. So that if a committer notices 3 consecutive timeouts, he can reset it to ports@ or to the submitter of the PR he's committing.

adamw edited edge metadata.

Looks good to me, and strangely, Mat's logic makes sense.

This revision is now accepted and ready to land.Aug 3 2016, 3:27 PM
This revision was automatically updated to reflect the committed changes.