Version 2.6.0 pushed to testing.

Suggested advisory :
Mageia 7 came with a release candidate version of nextcloud-client. This update brings an official upstream release, with some bug fixes.
Ref:
https://github.com/nextcloud/desktop/releases/tag/v2.6.0

SRPM :
nextcloud-client-2.6.0-1.mga7.srpm

RPMS:

nextcloud-client-2.6.0-1.mga7.aarch64.rpm
nextcloud-client-nautilus-2.6.0-1.mga7.aarch64.rpm
nextcloud-client-nemo-2.6.0-1.mga7.aarch64.rpm
nextcloud-client-caja-2.6.0-1.mga7.aarch64.rpm
nextcloud-client-dolphin-2.6.0-1.mga7.aarch64.rpm
lib64nextcloudsync0-2.6.0-1.mga7.aarch64.rpm
lib64ocsync0-2.6.0-1.mga7.aarch64.rpm
lib64nextcloud-client-devel-2.6.0-1.mga7.aarch64.rpm

Status: NEW => ASSIGNED

Probably OK;

It works well with my hired account at https://tribun.cloud/
This is Nextcloud 15.

But with the free non-admin account at same vendor: https://cloud.owncube.com, when configuring the client app and it launches Firefox for authentication when defining a new server to connect to, but server replies the log in token is not OK or have expired.  I believe this runs Nextcloud 17, maybe 16.

Maybe a transient problem at vendor - I have sent them a ticket and will try again tomorrow.

I have no NC server i run myself currently.

Created attachment 11314 [details]
crashed after fiddling with removing readding server endtoend encrypted

I had started it in konsole.

Here is output after it crashed after i fiddled with removing and readding server and endtoend encryption.

(In reply to Morgan Leijström from comment #3)

> Maybe a transient problem at vendor - I have sent them a ticket and will try
> again tomorrow.
> 

Another way to ensure this is not a regression, you can downgrade to the previous client, and see if the problem is still there.

Thank you José for handling this.
Assigning it to neoclust as the registered NextCloud maintainer, just for the form.

Assignee: bugsquad => mageia

Tested with an i586 system, all ok.

Created attachment 11315 [details]
v 2.6.0 with OwnCube Free client setup login v2 token fail

Somehow it is a regression: after downgrade to our 2.5.2, i can configure the client for https://cloud.owncube.com/ again.

Can someone else verify?
You do not have to have an account.
Just in the client try to add a server, enter https://cloud.owncube.com/ and your browser is supposed to launch a page where you can enter user name and password.

When i use client 2.6.0, i get login token fail, see attached shreenshot

In client log i see: [OCC::AbstractNetworkJob::slotFinished QNetworkReply::ContentNotFoundError "Error transferring https://cloud.owncube.com/login/v2/poll - server replied: " QVariant(int, 404)

First i think it is not problem with packaging, but some server side incompatibility.  But that too is strange as OwnCube have many customers and 2.6.0 is the recommended client version...

I am corresponding with OwnCube support about this.
That server runs NC17, APACHE/NGINX, MYSQL, PHP7.x.

Packaging: I think there should be an exact version dependency between the packages?
- It is possible now to i.e forget to update the libs. 

---

Android app: I can log in using my FP2 FPOpen Android phone with NextCloud app.

---

Reply from OwnCube support:
1. check my reply. test a other device, network....
2. there are more than 2838411 logins DAILY from other users without any issue
3. we tested 24 accounts on 12 devices in 8 networks and we cant reproduce this

And i thanked them for testing

---

I updated the server at https://tribun.cloud/ from v15 to v17, and now our packaged client -2.6.0-1.mga7 fail to register at both sites...

---

Is it just some quirk in my system?

- so please test if you too have problem or not with the test in comment 8: in client select to add server, and point it to https://tribun.cloud/ or https://cloud.owncube.com/

Minor note: When updating from 2.5.2 to 2.6.0, the client get set to autostart, even when i did not have the previous version to autostart.  I guess most people want it to autostart, so OK (but not me)

(In reply to Morgan Leijström from comment #9)
> Packaging: I think there should be an exact version dependency between the
> packages?
> - It is possible now to i.e forget to update the libs. 

It would be too much work. Only testers get this problem, mageiaupdate picks everything.

> - so please test if you too have problem or not with the test in comment 8:
> in client select to add server, and point it to https://tribun.cloud/ or
> https://cloud.owncube.com/

I could point, and nextcloud client opened a firefox window. All seems ok, even if I don't have an account @tribun.cloud or owncube.

In the light of comment 1, comment 2, which I managed to overlook, this should have been assigned directly to QA, and not to Nicolas at all. Sorry for angst.

Assignee: mageia => qa-bugs

Ah, i hit a *known problem*: https://github.com/nextcloud/desktop/issues/1412

IIUC, the problem comes from Plasma issuing an extra GET command before sending it to browser - so the token is already used when the browser opens the page...

* So it is trigged by client 2.6.0 + NC>=16 (new login flow) + KDE Plasma *

@José: I guess you use another DE than Plasma?

---

Description of the new login flow:
https://docs.nextcloud.com/server/17/developer_manual/client_apis/LoginFlow/index.html#login-flow-v2

---

  Workarounds;  1, 2, 3 works for me, but 4 NOT.

1) Use something else than Plasma; Under xfce it works for me too :)
Once an account is configured, the client works for that account in Plasma too.

2) set up the account using our old client version 2.5.2

3) set KDE to use a specific browser - so it do not send a GET first to see what contents come back and then choose application.
See https://user-images.githubusercontent.com/18538456/66551603-15f41080-eb48-11e9-94c3-5c15deecbe52.png

4) Launch the client from terminal, where you have first unset KDE variables
https://github.com/nextcloud/desktop/issues/1412#issuecomment-541312133
** BUT: This did NOT work for me!! **

---

So I would say that as a program it is validated OK

But: as most Mageia users use Plasma IMO we should add something about this bug in the advisory at least. And optimally some upgrade info that pops up at install/upgrade.

Something like: 

"This version 2.6.0 together with Nextcloud servers 16+ reveal a problem in combination with Plasma.  If you have problems connecting to a new server, see https://github.com/nextcloud/desktop/issues/1412#issuecomment-540458549, https://bugs.mageia.org/show_bug.cgi?id=25551#c13

Summary: Nextcloud client update request => Nextcloud client update 2.6.0 - with known quirk in Plasma

Hm yes method 3 have the odd side effect that each time the client is started, it need to launch the web page.  User do not have to enter credentials, just press a button.

(In reply to Morgan Leijström from comment #14)
> Hm yes method 3 have the odd side effect that each time the client is
> started, it need to launch the web page.  User do not have to enter
> credentials, just press a button.

No just once more, or glitchy.  Go figure.

In my case I set up a Nextcloud 13 server locally

Then installed the client:

The following 22 packages are going to be installed:

- lib64cloudproviders0-0.3.0-2.mga7.x86_64
- lib64gnome-keyring0-3.12.0-11.mga7.x86_64
- lib64minizip1-1.2.11-7.mga7.x86_64
- lib64nextcloudsync0-2.6.0-1.mga7.x86_64
- lib64ocsync0-2.6.0-1.mga7.x86_64
- lib64qt5keychain1-0.9.1-2.mga7.x86_64
- lib64qt5positioning5-5.12.2-2.mga7.x86_64
- lib64qt5printsupport5-5.12.2-2.2.mga7.x86_64
- lib64qt5quickwidgets5-5.12.2-2.mga7.x86_64
- lib64qt5sensors5-5.12.2-2.mga7.x86_64
- lib64qt5webchannel5-5.12.2-2.mga7.x86_64
- lib64qt5webengine5-5.12.2-2.mga7.x86_64
- lib64qt5webenginecore5-5.12.2-2.mga7.x86_64
- lib64qt5webenginewidgets5-5.12.2-2.mga7.x86_64
- lib64qt5webkit5-5.212.0-1.alpha2.24.mga7.x86_64
- lib64qt5webkitwidgets5-5.212.0-1.alpha2.24.mga7.x86_64
- lib64qt5xml5-5.12.2-2.2.mga7.x86_64
- lib64re2_0-20190401-1.mga7.x86_64
- lib64snappy1-1.1.7-2.mga7.x86_64
- libgnome-keyring-i18n-3.12.0-11.mga7.noarch
- nextcloud-client-2.6.0-1.mga7.x86_64
- qtwebengine5-5.12.2-2.mga7.x86_64

189MB of additional disk space will be used.

50MB of packages will be retrieved.

Is it ok to continue?

---

Did the configuration and it is working perfectly.


Should this be Okayed or not?

CC: (none) => brtians1

There is this issue i described in comment 13: with plasma default which we keep, the new login used in this client does not work, except if user do a workaround.

I if possible, i would like that user get informed of that during update to and install of client 2.6.0

Assignee: qa-bugs => lists.jjorge
Keywords: (none) => feedback

I wonder if there is a fix.

José - 2.6.0 still looks like the latest, are there any updates.

Morgan - I tried scenario to connect to owncube and it was able to work.

It opened the browser and linked the client.  This may be a conflict between the older client's hidden config file and the 2.6 config files.

Also - I'm running gnome on this machine.

Yes, the problem is with default behaviour of ** KDE Plasma **

By default it intercepts calls to internet to figure out what program to handle it, and in the process the one time token get used before the web browser is launched.  Workaround is described in 3) in comment 13.
Easy ** when you know it **.

And as Plasma is the most used DE on Mageia i think the workaround should be shown to users.

I agree - that should definitely be linked to.

However, I just did it on my plasma entity without issue (but it could be an oddball).

Now there is a mitigation in latest NextCloud *servers* around the KDE issue.

At november 9 both the latest point release of the server 16 and 17 got released with that implemented:
NC16.0.6 : https://github.com/nextcloud/server/pull/17689
NC17.0.1 : https://github.com/nextcloud/server/pull/17626
https://nextcloud.com/changelog/#latest17

So IMO we can release this client is, - iff we at least provide those server dot releases ourselves in Mageia.  Meaning we can say admins should update to latest point release (as always) but to say that we should provide latest version uåourselves...


However, there now is a client version 2.6.1 released with a couple of other important fixes, so IMO we should try to provide that client version directly.
https://github.com/nextcloud/desktop/releases

Keywords: feedback => (none)
Source RPM: nextcloud-client-2.5.2-0.rc1.3.mga7.src.rpm => nextcloud-client-2.6.0-1.mga7.src.rpm
Summary: Nextcloud client update 2.6.0 - with known quirk in Plasma => Nextcloud client update 2.6.1 (KDE quirk now mitigated in latest server)

I can test 2.6.1 in use.

They are so fun, they released the bugfix 15.0.13 version without applygin this patch. As always, we will only provide version 16.x as a backport, as it would break both our updates policy and upgrading from MGA6.

So for now, let's try to get this update pushed with client version 2.6.1 :

Suggested advisory :
Mageia 7 came with a release candidate version of nextcloud-client. This update brings an official upstream release, with some bug fixes.
Ref:
https://github.com/nextcloud/desktop/releases/tag/v2.6.0

SRPM :
nextcloud-client-2.6.0-1.mga7.srpm

RPMS:

nextcloud-client-2.6.0-1.mga7.aarch64.rpm
nextcloud-client-nautilus-2.6.0-1.mga7.aarch64.rpm
nextcloud-client-nemo-2.6.0-1.mga7.aarch64.rpm
nextcloud-client-caja-2.6.0-1.mga7.aarch64.rpm
nextcloud-client-dolphin-2.6.0-1.mga7.aarch64.rpm
lib64nextcloudsync0-2.6.0-1.mga7.aarch64.rpm
lib64ocsync0-2.6.0-1.mga7.aarch64.rpm
lib64nextcloud-client-devel-2.6.0-1.mga7.aarch64.rpm

(In reply to José Jorge from comment #23)
...
> So for now, let's try to get this update pushed with client version 2.6.1 :
...
> SRPM :
> nextcloud-client-2.6.0-1.mga7.srpm

Yes i forgot we are on old NC15...

You confuse me:

Do you intend to make 2.6.1 soonish for testing or do I OK this for 2.6.0 ?

You're right my rpms list was not updated. It is really the version 2.6.1 which is now in the testing medias, please test it.

Suggested advisory :
Mageia 7 came with a release candidate version of nextcloud-client. This update brings an official upstream release, with some bug fixes.
Ref:
https://github.com/nextcloud/desktop/releases/tag/v2.6.1

SRPM :
nextcloud-client-2.6.1-1.mga7.srpm

RPMS:

nextcloud-client-2.6.1-1.mga7.aarch64.rpm
nextcloud-client-nautilus-2.6.1-1.mga7.aarch64.rpm
nextcloud-client-nemo-2.6.1-1.mga7.aarch64.rpm
nextcloud-client-caja-2.6.1-1.mga7.aarch64.rpm
nextcloud-client-dolphin-2.6.1-1.mga7.aarch64.rpm
lib64nextcloudsync0-2.6.1-1.mga7.aarch64.rpm
lib64ocsync0-2.6.1-1.mga7.aarch64.rpm
lib64nextcloud-client-devel-2.6.1-1.mga7.aarch64.rpm

Thank you
2.6.1 updated and launced OK, will use it for a while and report.




(In reply to Morgan Leijström from comment #21)
> Now there is a mitigation in latest NextCloud *servers* around the KDE issue.
... 
> we should provide latest version uåourselves...


(In reply to José Jorge from comment #23)
> They are so fun, they released the bugfix 15.0.13 version without applygin
> this patch.


Ahh!  That is because the problem never existed in NC15 - Loginflow v2 got introduced in NC16...

:)

I have updated via the testing repo, and it is working with no problems at all.
regards peter

Upgraded to 1.6.1 and it is humming along here too, no regressions noted.

Tested to remove and readd account, add folders and sync.

I also tested the integration with dolphin OK. (showing sync status by icons on file icons, and right click menu)

Not tested integrations to nautilus, nemo, caja.  As integrations are not fatal i OK it and if any issue arise bugs can be opened.  We really need to ship 1.6.x!

Keywords: (none) => validated_update
Whiteboard: (none) => MGA7-64-OK
CC: (none) => sysadmin-bugs

Assigning back to QA as it can now be pushed.

Assignee: lists.jjorge => qa-bugs

José, why is the rpms list ".aarch64.rpm" ...only?

(In reply to Morgan Leijström from comment #30)
> José, why is the rpms list ".aarch64.rpm" ...only?

Well, you never asked why it was i586 or x86_64 only ;-)
The RPMS list is only here to ensure one subpackage is not forgotten, the arch is not important.

Using it for one week in my 32 bit laptop...

Whiteboard: MGA7-64-OK => MGA7-64-OK MGA7-32-OK

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2019-0215.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

Could i ask that we spawn a new version of this update request.
the latest version in mageia 7 no longer supports next cloud server 19.
although you can login, via the web link, no sync works at the directory level.
you will just see a grey cloud and a refusal to login.

regards peter

Bug 27380 - Update nextcloud-client to 3.0.2

Peter, could you test that version in updates testing and report back in that bug?