The current version of Rclone from the Fedora repo is 1.57.0. What isn't clear until you look more closely is that this is a development version. It identifies itself as:
rclone: Version "v1.57.0-DEV"
The upshot is that when connecting to Google Drive the authentication token expires after 7 days and has to be manually refreshed via a web page. This is a PITA for those of us who want to leave an rclone sync or mount daemon running in the background.
I discovered this on asking on the Rclone forum:
https://forum.rclone.org/t/google-drive-requires-manual-refresh-every-7-days...
I've now uninstalled the Fedora version and installed the "official" version from the Rclone site. I'll know if that solved the problem in a week's time.
Unlike most other packages, development versions of Rclone cannot avoid this issue because of the way they are registered by the Google API, so should not be distributed as part of the base system.
poc
On 02/02/2022 07:32, Patrick O'Callaghan wrote:
The current version of Rclone from the Fedora repo is 1.57.0. What isn't clear until you look more closely is that this is a development version. It identifies itself as:
rclone: Version "v1.57.0-DEV"
The upshot is that when connecting to Google Drive the authentication token expires after 7 days and has to be manually refreshed via a web page. This is a PITA for those of us who want to leave an rclone sync or mount daemon running in the background.
I discovered this on asking on the Rclone forum:
https://forum.rclone.org/t/google-drive-requires-manual-refresh-every-7-days...
I've now uninstalled the Fedora version and installed the "official" version from the Rclone site. I'll know if that solved the problem in a week's time.
Unlike most other packages, development versions of Rclone cannot avoid this issue because of the way they are registered by the Google API, so should not be distributed as part of the base system.
You may want to point out your observations on the "test" list and possibly even the "devel" list.
But, I would wait 7 days. :-)
-- Did 황준호 die?
On Wed, 2022-02-02 at 08:05 +0800, Ed Greshko wrote:
On 02/02/2022 07:32, Patrick O'Callaghan wrote:
The current version of Rclone from the Fedora repo is 1.57.0. What isn't clear until you look more closely is that this is a development version. It identifies itself as:
rclone: Version "v1.57.0-DEV"
The upshot is that when connecting to Google Drive the authentication token expires after 7 days and has to be manually refreshed via a web page. This is a PITA for those of us who want to leave an rclone sync or mount daemon running in the background.
I discovered this on asking on the Rclone forum:
https://forum.rclone.org/t/google-drive-requires-manual-refresh-every-7-days...
I've now uninstalled the Fedora version and installed the "official" version from the Rclone site. I'll know if that solved the problem in a week's time.
Unlike most other packages, development versions of Rclone cannot avoid this issue because of the way they are registered by the Google API, so should not be distributed as part of the base system.
You may want to point out your observations on the "test" list and possibly even the "devel" list.
I would if this were a test version of the RPM, but it isn't. It's the standard version from the base repo. I may file a BZ report.
But, I would wait 7 days. :-)
Yes, I'm doing that.
poc
Patrick O'Callaghan wrote:
I would if this were a test version of the RPM, but it isn't. It's the standard version from the base repo. I may file a BZ report.
It looks to me like that upstream doesn't consider anything but their binaries as official. :(
This might be due in whole or in part to having to register the app with the API for each supported service, but the effect appears to be that no one can build from source without hitting this limitation.
That is unfortunate, though I'm not sure the Fedora packages can fix it (upstream might not be able to either).
The package could patch `-DEV` out of the Version string in fs/version.go, though the packages do try to do that via LDFLAGS (refer to line 144 in the rclone spec file)¹.
I was curious and killing time avoiding real work, so I built the package with the version file patched instead of only trying to override it via LDFLAGS, to see if that reported the version without the -DEV. It does remove the '-DEV' suffix:
$ rclone version rclone v1.57.0 - os/version: fedora 35 (64 bit) - os/kernel: 5.15.16-100.fc34.x86_64 (x86_64) - os/type: linux - os/arch: amd64 - go/version: go1.16.13 - go/linking: dynamic - go/tags: none
I don't know if that's enough to allow the build to work without the 7-day limitation, as I don't use rclone. Please feel free to give that a try and see if it helps. It'd be great if it were that simple. If so, I can submit the change to the package maintainer easily enough.
The scratch build and package changes are at:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82292527 https://src.fedoraproject.org/fork/tmz/rpms/rclone/c/9ab47be63?branch=fix-ve...
It would be ideal if upstream and downstream packagers could come to some sort of arrangement to improve the situation. That presumes upstream would be interested in having builds which didn't come directly from their site.
¹ https://src.fedoraproject.org/rpms/rclone/blob/045ab834f/f/rclone.spec#_144
On Wed, 2022-02-02 at 12:22 -0500, Todd Zullinger wrote:
Patrick O'Callaghan wrote:
I would if this were a test version of the RPM, but it isn't. It's the standard version from the base repo. I may file a BZ report.
It looks to me like that upstream doesn't consider anything but their binaries as official. :(
This might be due in whole or in part to having to register the app with the API for each supported service, but the effect appears to be that no one can build from source without hitting this limitation.
That is unfortunate, though I'm not sure the Fedora packages can fix it (upstream might not be able to either).
The package could patch `-DEV` out of the Version string in fs/version.go, though the packages do try to do that via LDFLAGS (refer to line 144 in the rclone spec file)¹.
I was curious and killing time avoiding real work, so I built the package with the version file patched instead of only trying to override it via LDFLAGS, to see if that reported the version without the -DEV. It does remove the '-DEV' suffix:
$ rclone version rclone v1.57.0 - os/version: fedora 35 (64 bit) - os/kernel: 5.15.16-100.fc34.x86_64 (x86_64) - os/type: linux - os/arch: amd64 - go/version: go1.16.13 - go/linking: dynamic - go/tags: none
I don't know if that's enough to allow the build to work without the 7-day limitation, as I don't use rclone. Please feel free to give that a try and see if it helps. It'd be great if it were that simple. If so, I can submit the change to the package maintainer easily enough.
The scratch build and package changes are at:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82292527 https://src.fedoraproject.org/fork/tmz/rpms/rclone/c/9ab47be63?branch=fix-ve...
It would be ideal if upstream and downstream packagers could come to some sort of arrangement to improve the situation. That presumes upstream would be interested in having builds which didn't come directly from their site.
¹ https://src.fedoraproject.org/rpms/rclone/blob/045ab834f/f/rclone.spec#_144
That's an interesting proposal. I'll have to wait to test it because of the 7-day timeout (I don't know a way of speeding that up) but in the meantime I'll pass this on to the Rclone forum to see if there's a response.
poc
On Wed, 2022-02-02 at 22:26 +0000, Patrick O'Callaghan wrote:
It would be ideal if upstream and downstream packagers could come to some sort of arrangement to improve the situation. That presumes upstream would be interested in having builds which didn't come directly from their site.
¹ https://src.fedoraproject.org/rpms/rclone/blob/045ab834f/f/rclone.spec#_144
That's an interesting proposal. I'll have to wait to test it because of the 7-day timeout (I don't know a way of speeding that up) but in the meantime I'll pass this on to the Rclone forum to see if there's a response.
Well, I waited the requisite 7 days using the "official" rclone build and the issue remains exactly the same. From discussion on the Rclone forum it looks like the only ways to get round this are a) use the build's own built-in default credentials, which are rate-limited in some way, or b) set up a "service account" via Google Workspace. I do in fact have a GW account so I may end up doing this, but it's hardly a general-purpose solution. Fedora could presumably also do it as an institution, but I don't expect that to happen.
It may be more productive to look into ways of scripting the interactive refresh dialogue to allow it to be hands-off, but I'm not sure how feasible that would be.
poc
-
Ed Greshko -
Patrick O'Callaghan -
Todd Zullinger