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.
1 Like
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
1 Like
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 
1 Like
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.
2 Likes
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
2 Likes
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.
1 Like
Hello,
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
Oh, youāre 100% right, that is an issue - as you say, the best would be to have the package in the official distribution.
With regards to promising to maintain the client X years, yeah, that is something we should consider doing. At the moment we still have to built up a client team, and weāre not in a hurry as the consultants hired by oC to work on it right now are good guys, friends of us (markus, olivier et all) and they do a good job. We feel no need to interfere with them right now, heck, when oC closes shop or for another reason stops paying them, we will probably pay their bills going forward.
Of course, we need to add features to the client rather than having it in some kind of limbo maintenance mode, so we do have job openings and will hire people for the client. And once that team is at strength we can make promises about support.
A constraint here is that a part of our business model is that we offer customers a way out from the upgrade thread mill: we offer 5-15 year support on Nextcloud. If weād do that for free, thatās a reason less to pay us, not something we would do lightly. But that mostly is about the server, less the client, so we have to see. I just want to be 100% transparent here, not make promises we canāt keepā¦
BTW to everyone but you, mr @tflidd in particular: GO HERE. Seriously.
1 Like
OK, I have just created a pull request.
2 Likes