I did this, changing my install directory name to
/var/www/nextcloud. The only issue that I had was my background task cron job was now trying to execute a file in the old directory. Once this was updated all went smoothly.
I did this, changing my install directory name to
The upgrade went very well. I used the manual upgrade process from ownCloud 9.1 (deleting the specified owncloud files on my shared hosting and replacing them with the nextCloud files). I just needed to disable the maintenance mode before I could proceed with the web update. I have one question:
I have a tagspaces folder in my nextCloud folder that is currently failing the code integrity check: > There were problems with the code integrity check.
Is there a way to disable this check for the files in this folder?
It worked flawlessly for me as well.
But Contacts and Calendar still have to be enabled manually.
I really hope these will become first class citizens, as promised.
This has been a cumbersome thing from the beginning: upgrading and reenabling these two for each upgrade & release have driven me mad. I feel I have never had a simple, direct, upgrade process with owncloud.
Only solution should be to move this folder out of your nextcloudinstallation…
Unless the packages were configured in rather stark violation of how Debian packages are supposed to be set up, an uninstall shouldn’t be deleting any configuration files (only a purge should).
This is one of the nice things about proper package management, it makes things simple without any “gotchas” for the users. I’m quite disappointed that you’re ditching the repo, it’s a major step backwards in user-friendliness, frankly (and the only thing you folks have done so far that isn’t quite reassuring and laudable).
After the migration is my app Gallery missing. I can’t found the app anymore.
I have my owncloud installation in the root of the webserver and since it is already linked to a subdomain from another hosting provider I am not sure how to change this. Is there something the tagspaces https://github.com/tagspaces/tagspaces dev can do to the files so they are for example recognized as a (special) app of nextcloud?
Just my 2 cents. At least for me the absence of supported Ubuntu/Debian packages means that Nextcloud is not a drop-in replacement for the other one. Integrating yet another new mechanism in my server admin processes is time-prohibiting for the time being.
Have you checked under “Apps” that it isn’t just disbled? If it is, just click the “Enable” button next to Gallery in the apps section.
I search in mijn app list and i can’t found app Gallery. Not in installed, enabled and rest of other tabs.
What about in “Not enabled”?
As noted at Test our new work-in-progress upgrader script we do also now have a new work-in-progress upgrader that also could be used for the purpose of migrating to Nextcloud.
Testing very much welcome.
Thant won’t be of much use I fear. If Debian packages nextcloud we’ll have packages which are years out of date in the stable distribution (probably with security patches). I guess this is fine for some use cases, but absolutely no replacement for the up-to-date packages provided by owncloud.
Can you elaborate what the problem is with the current packaging method used by owncloud?
Aside from it being the full-time job of one person and breaking things for users about every release, it results in being yelled at by distribution people who don’t like that the packages do not follow all the various and conflicting policies for each distribution, which results in them claiming the packages are low quality. Which might or might not be true depending on your pov but in any case it isn’t work which results in many grateful emails about how nice it is that there are packages.
Now customers might need packages for RHEL or something and we will have to provide those but on the community side I and the others strongly prefer to rely on volunteers. This isn’t company policy or anything, note, it is just how most of the employees think about it and as we’re a company that works bottom up rather than having management meetings, this is pretty much the current state of affairs
If you or others have a good reason to not hire somebody for coding or sales but, instead, for packaging - I’m all ears and I am sure so are the others. But it will have to be somebody with a very thick skin, willingness to package for a wide variety of distributions AND be darn good at it so it doesn’t break or change every 2nd release.
[quote=“jospoortvliet, post:49, topic:551, full:true”]
Aside from it being the full-time job of one person and breaking things for users about every release[/quote]
C’mon, things broke for users about every release for a wild variety of reasons. Upgrading owncloud has been a rough experience at the best of days. Just to give one example: remember someone changing the URL pattern for caldav/carddav between two versions of OC? It broke functionality for clients using the legacy pattern. And that’s just one example. No need to single out the Debian packages here. I can’t remember a single issue caused by the packages, but that’s not to say they weren’t there.
I didn’t mean to single those out, and it wasn’t the Debian packages but all of them. And with ‘breakage’ I mean that in every other release I heard the days before or (more often) after the release I had to inform people our packages had moved to a new repo, had been renamed, dropped support for one or another platform and so on and on. There’s plenty more broken, for sure, but packages didn’t work well. I’d rather follow the example of Wordpress and provide a great built in updater. See also http://lists.automattic.com/pipermail/wp-hackers/2010-June/032483.html
[quote=“jospoortvliet, post:51, topic:551, full:true”]I didn’t mean to single those out, and it wasn’t the Debian packages but all of them.[/quote]We could well stop developing new features if the risk of breaking something is unacceptable. But I never heard that argument before.[quote=“jospoortvliet, post:51, topic:551, full:true”]And with ‘breakage’ I mean that in every other release I heard the days before or (more often) after the release I had to inform people our packages had moved to a new repo, had been renamed, dropped support for one or another platform and so on and on.[/quote]The decision to play around with the repos was misinformed in my opinion. Sure does it make upgrading more difficult. You can’t blame the repo-mechanism for that; it was an entirely arbitrary decision. Not different from changing the URL patterns I made reference to.[quote=“jospoortvliet, post:51, topic:551, full:true”]There’s plenty more broken, for sure, but packages didn’t work well.[/quote]For me it did work insofar nothing else kept owncloud from upgrading.[quote=“jospoortvliet, post:51, topic:551, full:true”]I’d rather follow the example of Wordpress and provide a great built in updater.[/quote]The packages at the repo did more than just update owncloud. The whole dependency tree was managed by it.
I know. I used them, too… I’m not against packages. I’m against having us provide them, unilaterally, rather than the distributions.
What about the packages
owncloud-deps-php5 owncloud-files, can they be removed as well?