Package Request: Update Grive

[crborga]

Currently Grive in the repos doesn't work as Google changed something since that build.

Grive is found at: https://github.com/vitalif/grive2

Grive simply downloads all the files in your Google Drive into the current directory. After you make some changes to the local files, run grive again and it will upload your changes back to your Google Drive. New files created locally or in Google Drive will be uploaded or downloaded respectively. Deleted files will also be "removed". Currently Grive will NOT destroy any of your files: it will only move the files to a directory named .trash or put them in the Google Drive trash. You can always recover them.

Minor changes to the control will make it build with gcc8 which is what I did to mine like this pull request here. https://github.com/vitalif/grive2/pull/321

[Stevo]

Google decided to stop trusting grive, so it doesn't work any longer without the user doing a lot of shenanigans you can see in the issues on that github link. Too much trouble for me...

Our MX grive already is build on gcc-8, too.

[crborga]

It works you just have to make your own api key, the repo version does not though.

[SwampRabbit]

It works you just have to make your own api key, the repo version does not though. The package I built below works but I thought the repo should be updated or just remove it if you don't want to support it.

https://mega.nz/file/S0oHlbLK#8pl59z2iR ... i0ic3ODEKQ

I'm not up to speed on grive, but if its a matter or creating an api key pre or post install, then that is something the grive developers should include as part of the install routine. (if that is what is needed to be done)
I suppose we could create a pre-install script as part of our package, but really the upstream developers of grive should be doing this so it is reproducible during packaging, if that is even possible.

Creating a local .deb with your own API key is not the same as creating the same sort of package for our repos. Pretty sure users can't use someone else's API key in this instance, really they shouldn't be either.

Its not that we don't want to support grive, but as Stevo essentially said, we can't spend too much time and energy on fixing or working around issues with an application just to package it.

It would be much easier just to write a HOWTO install grive and create an API key. But if this application is very volatile .. that HOWTO could be obsolete in no time.

grive is something to look into, like I said I'm not up to speed on it right now.

[crborga]

I am aware that package signing and a api key are separate things.

[SwampRabbit]

I am aware that package signing and a api key are separate things.

I think there is some confusion though, I'm not comparing the two or saying they are separate (although they are).

I am saying that I don't believe we (or anyone else) can provide an API key with a package to users, they need to get their own for each user, is that correct?
They can do it manually or it may be able to be done by grive during install, but this isn't something MX should do (I think we could), but I think the grive developers should implement this. (if even possible).

I am also saying that we do not only provide .debs in our repos (at least that is the goal, don't think we do at all, could be wrong for some strange package).
We build reproducible builds in a clean schroot environment, this schroot does not have internet access during the build process (per Debian standards).
We provide the upstream source code tarball, debian tarball, and .deb. Signing is just the last step in that process. They are reproducible and verifiable.

[crborga]

Sounds like you should just remove it from the repo then and lets users manage it on their own.

[SwampRabbit]

Sounds like you should just remove it from the repo then and lets users manage it on their own.

Sounds like the best option until a better solution can be found.