Bug 1320542

Unfortunately upstream moved the calendar, contact and documents apps from core to the store.

Mails were sent to the Fedora users and development mailing lists, a Fedora Magazine article and comments on the bodhi update about it.

https://bodhi.fedoraproject.org/updates/FEDORA-2016-271438cff3

https://fedoramagazine.org/owncloud-updates-coming-soon-fedora/

During the upgrade the apps get disabled automatically and it's important to ensure the store works before enabling so they get the correct version.

You can be sure the store is working as there will be the categories on the left, not just the enabled/disabled sections.

There was no need to manually unpack though.

It's possible to use occ at the CLI to enter maintenance mode (or do it from config.php) and then use occ to disable the old app before using the web interface to install the newer from the store.

You don't need the API URL in config.php ... That can be removed and it'll have the right one in the code.

As it's an upstream issue not sure what more I can do than the mails and article.

Perhaps in the 8.2 update document recovery in the readme?

(In reply to James Hogarth from comment #1)
> Unfortunately upstream moved the calendar, contact and documents apps from
> core to the store.
> 
> Mails were sent to the Fedora users and development mailing lists, a Fedora
> Magazine article and comments on the bodhi update about it.
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2016-271438cff3
> 
> https://fedoramagazine.org/owncloud-updates-coming-soon-fedora/
> 
> During the upgrade the apps get disabled automatically and it's important to
> ensure the store works before enabling so they get the correct version.
> 
> You can be sure the store is working as there will be the categories on the
> left, not just the enabled/disabled sections.

exact, that's what is missing in my setup, which is confirmed by these messages in the log :

Mar 23 19:23:11 lxorgfr ownCloud[12427]: {core} Could not get application: Client error response [url] http://api.apps.owncloud.com/v1/content/data/168707?version=8x1x5x2 [status code] 404 [reason phrase] Not Found
Mar 23 19:23:11 lxorgfr ownCloud[12427]: {core} Could not get application: Client error response [url] http://api.apps.owncloud.com/v1/content/data/168708?version=8x1x5x2 [status code] 404 [reason phrase] Not Found
Mar 23 19:23:11 lxorgfr ownCloud[9796]: {core} Could not get categories: Client error response [url] http://api.apps.owncloud.com/v1/content/categories?version=8x1x5x2 [status code] 404 [reason phrase] Not Found

but... I see the root of the problem now, the appstoreurl changed. And according the the source code, it should be now https://api.owncloud.com/v1 instead of  http://api.apps.owncloud.com/v1

For the record, I removed appstoreurl from config.php, but also proxy and proxyuserpwd. These empty proxy settings were also causing "cURL error 56: Proxy CONNECT aborted" errors, after OCE picked up the right appstoreurl.

Thanks for your help,

I also had a problem with updating the apps from the calendar and contact apps from the web UI, when going to the not-enabled tab, there was no update option shown in the web UI, and the following error was seen in the log file:
Mar 25 21:59:36 juran.se ownCloud[1491]: {core} Could not get application: Client error response [url] http://api.apps.owncloud.com/v1/content/data/168708?version=8x1x5x2 [status code] 404 [reason phrase] Not Found

Following Fabrice's advice above, I commented out the "appstoreurl" from /etc/owncloud/config.php and restarted httpd.

Now when visiting the not-enabled apps tab, a update-app button was available. Clicking on this one however gave the following error in the log files:

Mar 25 22:06:44 juran.se ownCloud[4201]: {router} Exception: {"Exception":"Symfony\\Component\\Routing\\Exception\\RouteNotFoundException","Message":"Unable to generate a URL for the named route \"contacts_index\" as such route does not exist.","Code":0,"Trace":"#0 \/usr\/share\/owncloud\/lib\/private\/route\/router.php(317): Symfony\\Component\\Routing\\Generator\\UrlGenerator->generate('contacts_index', Array, false)\n#1 \/usr\/share\/owncloud\/lib\/private\/urlgenerator.php(65): OC\\Route\\Router->generate('contacts_index', Array)\n#2 \/usr\/share\/owncloud\/lib\/private\/helper.php(139): OC\\URLGenerator->linkToRoute('contacts_index', Array)\n#3 \/usr\/share\/owncloud\/lib\/public\/util.php(306): OC_Helper::linkToRoute('contacts_index', Array)\n#4 \/var\/lib\/owncloud\/apps\/contacts\/appinfo\/app.php(18): OCP\\Util::linkToRoute('contacts_index')\n#5 \/usr\/share\/owncloud\/lib\/private\/app.php(139): require_once('\/var\/lib\/ownclo...')\n#6 \/usr\/share\/owncloud\/lib\/private\/app.php(120): OC_App::requireAppFile('contacts')\n#7 \/usr\/share\/owncloud\/lib\/private\/app.php(1173): OC_App::loadApp('contacts', false)\n#8 \/usr\/share\/owncloud\/lib\/private\/installer.php(218): OC_App::updateApp('contacts')\n#9 \/usr\/share\/owncloud\/lib\/private\/installer.php(248): OC_Installer::updateApp(Array)\n#10 \/usr\/share\/owncloud\/settings\/ajax\/updateapp.php(53): OC_Installer::updateAppByOCSId('168708')\n#11 \/usr\/share\/owncloud\/lib\/private\/route\/route.php(154) : runtime-created function(1): require_once('\/usr\/share\/ownc...')\n#12 [internal function]: __lambda_func(Array)\n#13 \/usr\/share\/owncloud\/lib\/private\/route\/router.php(283): call_user_func('\\x00lambda_310', Array)\n#14 \/usr\/share\/owncloud\/lib\/base.php(878): OC\\Route\\Router->match('\/settings\/ajax\/...')\n#15 \/usr\/share\/owncloud\/index.php(48): OC::handleRequest()\n#16 {main}","File":"\/usr\/share\/php\/Symfony\/Component\/Routing\/Generator\/UrlGenerator.php","Line":130}


And the "enable" button stayed greyed out. After re-loading the page however, the button "enable" button was clickable, and so far, it seems the aps are working.

The current version in Fedora and EPEL now has information about this in the readme installed in docs.

Hopefully the 8.2 upgrade went smoother for you with the testing from the initial 8.1 upgrade!

Since the 8.2 version has been out a little while now closing this as the visibility of the issue to others is no longer helped by the open bug.