Works great on Ubuntu 16.04!
works fine on my Linux Mint 17.3 Cinnamon, Thanks
Installed on 16.04, but I faced a crash on first login with a missing letter in the url of my Nextcloud instance, then all good, it is currently syncing.
Thanks a lot.
Works great! Thank you for this!
I basically take the Git repository containing the nextcloud theme (i.e. the one mentioned on the download page), add the debian directory with the necessary files and create a source package using “debuild -S”. I use the CDBS support for cmake, so the building is really simple: I only have to set a few variables in the “debian/rules” file.
I then upload the source package to the PPA using “dput” and it then gets built into the binary packages.
I have some scripts to automate most of the building (and to test the building locally) on my machine. If interested, I can share them along with the files in the “debian” directory. However, if you download the source (apt-get source nextcloud-client), you can get the “debian” files.
2 posts were split to a new topic: How to migrate your owncloud desktop client to Nextcloud
Confirmed working on Deepin 15.3 as well (Debian unstable). Though you have to change the zesty distro to trusty.
@ivaradi If you ask me this PPA should transform to Nextcloud where you become the maintainer. What does others think? Maybe create a new repo called “client_ppa” and add it there? https://github.com/nextcloud/client_theming
I would prefer to have it move to Debian/Ubuntu instead, the distro’s should maintain this, not our community. Distro’s have their review process, they are the experts etc… But I wouldn’t want to block if you foik think it should be in our repo ofc.
@jospoortvliet With all due respect, but then we’d loose control over it. We have to make sure things are working and are maintained.
Wasn’t this an issue with OC? As long as there’s skill on board NC, I don’t see a reason not to maintain it inhouse.
Awesome, seems to be syncing fine for me. Ubuntu 16.04. This is definitely useful.
I have no experience with maintaining packages but moving this to the distros must make it more difficult to update (at least delayed)? I think the ideal state would be the client being a snap for easy rollback to a working version if things go wrong in a future update as well as more universal usability? If my understanding is correct the project would maintain near full control? This might remove the demand for a rpm version as well? Again, I’m a complete novice, a PPA works well for me currently. Thanks!
Well, thing is - we got in quite some conflicts with distro’s about us packaging by ourselves in the oC times. Quality was also an issue, it isn’t too crazy hard to do a reasonable package but a real good one is very hard. In general, I’m not at all opposed to us offering packages where the distributions don’t but if they pick it up I don’t want to interfere, if we can.
That sounds easier than it is, as we can say that providing newer packages would be a good thing to do - distro packages on anything but a rolling release are almost by definition outdated. I think we should be careful with that, already, and for sure present that as an alternative, not the recommended route.
Where that results in a sub-optimal user experience (eg old clients with known bugs being shipped by distro’s, as often happened in the past) we can point people to our packages but as alternative - tell them to talk to their distro first, that is where the solution should be.
Does this make sense?
Again, for now - yeah, I’m happy to point to inofficial, community-provided repo’s, and we can put the work being done in our project, too. But let’s please be very clear: the distributions should be packaging, not us. The Linux world continues to be fundamentally hostile to projects building and distributing their own software and trying to fix that isn’t our job. Let the Snappy/Flatpack/systemd folks do that, it’s their thing
Can’t argue with that. If I were a dev I’d feel weird leaving it to 3rd parties to build and distribute my software exactly for the reasons around outdated versions and a lack of control. OpenSUSE offer a nice service hosting builds for all distros for developers (which I think I last used for Sonarr) as a self-managed option but I guess it comes down to what you want, and sounds like you know
Having the package in the official distros would be the best solution. However, after the last experiences it’s not surprising that this community is a bit careful and not too enthusiastic about it (mostly speaking for debian). Would it be helpful to reach out to the community, e.g. by saying that we support the current client with security fixes throughout the lifetime of Debian Stretch (to be released in 2017, support until 2019/20) and then perhaps provide an upgrade path to the client version which is released then. Or do you expect them to backport everything themselves? Or is it possible to handle this like Firefox updates which also release more frequently (I don’t know how this is currently managed).
Problem for non-NC maintained packages, someone is provide a private repo. Let’s say in the future, they abandon Nextcloud and all users are hanging on the outdated 3rd party repos. As we don’t control these repos, it depends a lot on these people if they stay with NC and if not, if they transfer the account to a new maintainer, … many things we don’t control.
Test passed. Partly. With GoogleDrive mounted as external storage and encryption module enabled for external storage I got a lot of sync errors (unable to download, zero byte file, …). No files were deleted but the download of most files failed. Then I disabled the GoogleDrive external storage for my user account and everything is working now.
I cannot tell if this is a general bug with handling external, encrypted storage or a specific problem with this client.
Server: Nextcloud 11 (beta channel) test environment
Client: nextcloud-client (2.2.4-1.0~yakkety1) Ubuntu 16.10
I guess this comes of the Google office files like tables. They can’t be synced with Nextcloud (please correct me if i’m wrong).
Just wanted to report here, that for some weeks now, we have nextcloud-client packages for Fedora and Epel7 (CentOS and RHEL) available in the distribution repositories: https://apps.fedoraproject.org/packages/nextcloud-client
Exactly my point. That’s why it’s better to at least move this PPA to the Nextcloud repo. What I meant was not releasing our own client-distro, but using a PPA to do so.
what do you mean exactly by moving the PPA to the Nextcloud repo?
Put the PPA fles in the Nextcloud repo on Github.Something like this maybe: https://github.com/Bumblebee-Project/bumblebee-ppa