This is not needed either. I checked that the date imprinted on the doc pages correspond to the source last modified date and not the build date. The variable SOURCE_DATE_EPOCH takes care of this. Therefore, we do not need this patch at all. Thanks.

I can no longer sync against a server that I do not host myself.

Isn't that something that should become a Bugreport against the used server? If the server is not working with a client version that - in turn - works with other server versions... ...wouldn't it be worth to get the two development groups to work together?

But it looks like we are talking about Owncloud vs. Nextcloud here (please correct me, if I'm wrong): in that case - especially as Nextcloud forked from Owncloud in the past for a reason - I would expect no solution. Ever. So it might be better to NOT expect/ recommend users to use the nextcloud-desktop package to connect to an Owncloud server in that case -- and instead recommend them to use a dedicated owncloud-desktop package?

I am wondering anyway, that the nextcloud-client still works with an Owncloud server ;-)

As long as we do not know for sure what versions this does and doesn't affect, I would suggest holding off on the update.

The less testing this version gets, the more problems might get in unnoticed. At the moment, none of the nextcloud-desktop users in openSUSE Tumbleweed have a chance to test - which is not really useful for them or any potential user of the next Leap version.

The workaround you mention is clearly not a feasible solution those who do not have control over the server configuration, which is probably most people.

As said: if Nextcloud 25.x is affected as well, I would expect upstream to react, if more people complain about a non-working client. If nobody cries, the pressure for upstream to look at the issue is very low...

Clearly, upstream has decided to introduce what seems to be a major feature into what going by version numbering should have been a bug fix.

We are not responsible for upstream version numbering. We never will. If Upstream decides to name the next version 10.0 or 1.00 is up to them. (Remember that openSUSE switched from 42.3 to 15.0 ?)

As I noted upstream, I could also revert the commit that introduces this "feature" and push everything else that versions 3.9.1 through 3.9.3 bring, but still waiting word from upstream as to whether that would be safe to do.

If you want to wait, you should IMHO claim an ETA, until you expect upstream to provide a fix. This is clearly not a security issue (thinking about coordinated release dates and responsible behavior of distributions and upstream people when it comes to security bugs), but without a responsible and clearly expressed behavior, nothing will go forward.

So what about communicating a clear deadline for an upstream fix. If this date is passed, release the latest version in Tumbleweed?

Atri Bhattacharya (badshah400) - 9 months ago

target maintainer

According to this comment upstream, NextCloud server 25.0.x is affected as well. It does not seem like a server version or owncloud vs nextcloud issue but rather that all of a sudden some specific server configurations will become unusable after updating from 3.9.0 to 3.9.1.

If your point is to let this broken update loose upon the TW population as a test, I think I can go along with that. I suppose it will be possible to revert back to 3.9.0 if we get too many complaints, won't it? I genuinely do not know if we can do that, so please let me know. If so, let's go for it.

Thanks for the discussion.

We have resumed pushing the latest versions to factory for a while now already. JFYI