I added Nextcloud 21 on backport_testing: src.rpm: nextcloud-21.0.0-1.mga8 rpms: nextcloud-21.0.0-1.mga8 nextcloud-mysql-21.0.0-1.mga8 nextcloud-postgresql-21.0.0-1.mga8 nextcloud-sqlite-21.0.0-1.mga8 Advisory: When mageia 8 have been released Nextcloud 21 wasn't yet available. As mageia 8 have been released with php we couldn't provide nextcloud 20. This backport provide a php 8.0 compatible version.
Thank you for doing this Nicolas. Assigning it directly to QA. I think in the Advisory "As mageia 8 have been released with php we..." was meant to be "As mageia 8 has been released with php 8 we..."
Summary: Nextcloud 21 => Nextcloud 21 backport to work with PHP8 in Mageia 8Assignee: bugsquad => qa-bugs
Hi all I just tested it and it works. It is not "smooth" though. I still get an error while checking the server configuration with the web interface. I got a server error as well while navigating across the menu and no error in the journal. I have not been able to reproduce it though. But it is a good sign as it is still a 21.0.0 version.
CC: (none) => chb0
Created attachment 12428 [details] server check error with the web interface After going into Overview, a server configuration check is done and leads to the attached error.
That error can be ignored unless nextcloud refuses to continue. The error is complaining that http is being used instead of https and that the web server has not been configured to return webfinger or nodeinfo results. When accessing localhost, I see no reason to require https. As to adding the webfinger or nodeinfo results, I see no reason they should be considered "required". I do not consider these to be errors, so unless nextcloud refuses, they should be considered information messages.
CC: (none) => davidwhodgins
Yes, but the error in red, above the http warning? I believe it is separate, to me it say the checking procedure itself fail...?
CC: (none) => fri
Since that message includes no details, I assumed it was due to the following messages.
I suggest enabling of displaying/logging all php errors to get an idea what it complains about...
Hi HTTPS complaint and server check error are not related. HTTPS message is always here when connecting via localhost. Nextcloud journal is empty. Thomas, How can I enable the display of all PHP errors?
is anymore testing needed on this or are we waiting on more patches?
CC: (none) => brtians1
§ Per comment 8, self check fail in test by Christian § 20.0.1 is due within two weeks, probably containing a bunch of bugfixes. So it may be worth to skip this 20.0.0. https://github.com/nextcloud/server/milestones § Nicolas wrote 20 mar on doc-discuss: "i will soon in cauldron split nextcloud to provide apache/nginx config to help out of the box installs " I think that may be interesting to ship already like that in mga8 if possible with this first mga8 NC package, as we have not yet released a mga8 NC.
I meant test fail in comment 2
ok i take it back to add all this :-)
Assignee: qa-bugs => mageia
That's a fighter ;-)
21.0.1 out upstream yesterday https://nextcloud.com/changelog/#latest21 :)
21.0.2 today.
Let me know when this ready, I'll build out a new server instance to mess with it.
Hi to be aware of : https://github.com/nextcloud/server/issues/25806
21.0.3 july 2
22.0.0 went out july 6 but remember we need to first have 21.x And IMO it is for 22 wise to wait for at least 22.0.1 bugfix release.
People wanting NC21/22 and find this bug not resolved, consider manual install: https://wiki.mageia.org/en/Nextcloud#Ways_to_install
For packaging, consider Bug 29293 - Nextcloud error: APCu not available for local cache, corrected by manual adjustment of our 99_apcu.ini
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=29293
Hi after upgrading my server to 21.0.4, the log is now clean, and I don't have any functionality issue. We might have now reached enough maturity with NC21.0.4 to roll it our with php8 (8.0.9 in my case).
Hi Nextcloud 22 was released about 1 month ago in the stable branch. As we are a bit cutting edge with php8, what about skipping NC21 to propose directly NC22?
Skipping a major version on upgrade is not supported. (unless there is news on that?)
Has NC21 been really introduced in Mageia 8? If not, no version will be skept. Plus, NC21 will reach end of life before Mageia9 is released.
We are late on this, but people running NC on mga7 want to upgrade to mga8 withourt breaking the cloud server install. We have provided similar ownCloud/Nextcloud upgrade paths for previous Mageia releases, see https://wiki.mageia.org/en/OwnCloud#News And we have told users we will now too, see https://wiki.mageia.org/en/Mageia_8_Release_Notes#Nextcloud By your comment 22, it should work nicely. Once we package NC21 for mga8 per ideas higher up in this thread, i suppose packaging 22 too the same way will be relatively easy.
(In reply to Morgan Leijström from comment #26) > We are late on this, but people running NC on mga7 want to upgrade to mga8 > withourt breaking the cloud server install. > Is NC20 proposed in the MGA7 repo ?
NC20.0.4 is in mga7 backports since 2021-01-10
(In reply to Morgan Leijström from comment #28) > NC20.0.4 is in mga7 backports since 2021-01-10 Ok, it will work then.
Hi. Morgan just suggested me to help to complete this Nextcloud package. I think it is a good idea as I am also looking for a mentor to become a packager ;) I will be a kind of hands-on education :) Who is the packager for Nextcloud? Is it you Nicolas? How could I help? Just let me know.
Great Christian :) A few notes: I wonder if NC21.latest better be pushed to core updates (not backports), so it will be upgraded on a mga7 to mga8 upgrade. (I think we wish to avoid NC20 which is else left from mga7 starting and failing, or it does not matter? - but anyway i guess you two have better knowledge on pros and cons for that than me) NC22.latest should go in backports. And yes if NC21 is not perfect with our NC21, it is good to push it too ASAP, so NC21 only is used as a stepstone for them who install fresh, they can go directly to NC22 as soon as we release it. (side note: both suggestions above is against our normal use of updates and backports, but that is as usual for this package, because Nextcloud must have more frequent main version updates than we release a new Mageia.) Note there are packaging changes in the works which differ from Mageia 7, and clean upgrade from Mageia 7 must be tested: From comment 10: "split nextcloud to provide apache/nginx config to help out of the box installs" (per comment 12 intended to be worked on) IIRC there was also some changes in adaptation to databases, the nextcloud-<database> packages. I leave to Nicolas to take it from here
(In reply to Morgan Leijström from comment #31) > I wonder if NC21.latest better be pushed to core updates (not backports), so > it will be upgraded on a mga7 to mga8 upgrade. (I think we wish to avoid > NC20 which is else left from mga7 starting and failing, or it does not > matter? - but anyway i guess you two have better knowledge on pros and cons > for that than me) Experience has shown that will break nextcloud installations that are not currently running nextcloud 20. We made the mistake once of putting a update for nextcloud in updates instead of backports, so doing it again is not an option.
(In reply to Dave Hodgins from comment #32) > (In reply to Morgan Leijström from comment #31) > > I wonder if NC21.latest better be pushed to core updates (not backports), so > > it will be upgraded on a mga7 to mga8 upgrade. (I think we wish to avoid > > NC20 which is else left from mga7 starting and failing, or it does not > > matter? - but anyway i guess you two have better knowledge on pros and cons > > for that than me) > > Experience has shown that will break nextcloud installations that are not > currently running nextcloud 20. We made the mistake once of putting a update > for nextcloud in updates instead of backports, so doing it again is not an > option. I am not sure I fully follow what you are after. Let me try to complement in order to converge. If the question is what version should be running with MGA7 before upgrading to MGA8, one has to bear in mind only version 21 (and 22) can run with MGA8 because of php8. So, either we get the user to run NC20 with MGA8 and we must upgrade to NC21 while upgrading to MGA8, or we get the user to run NC21 with MGA7 and there is nothing to do while upgrading to MGA8. Personally, NC major version upgrade introducing some risks depending on the applications installed, I would be more comfortable with testing first the NC update is fully functional.
While people running nextcloud under Mageia 7 should be currently running nc20, they may still be running nc19. Putting nc21 in updates would install it as part of the upgrade from 7 to 8, breaking the nc install. I haven't looked at what's involved in updating a nc install in a long time. While nc19 may not run under mga8, can the user manually do the upgrade to nc20 in the same manner as usual? I believe it's in the best interest of the people using nc to keep the nc upgrade process as consistent as possible.
As Dave say we should normally never put update of nextcloud in updates. But now when the upgrade of Mageia upgrade PHP, Nextcloud *will* malfunction if it is not upgraded too, due to incompatible PHP. Users running Nextcloud on mga7 have had since january to upgrade to our NC20 package. It is already old (...optimally we should have shipped another NC20.later mga7 update before, but we are low on folks) We prominently state users *must* upgrade nextcloud to 20 before upgrading Mageia both in https://wiki.mageia.org/en/Mageia_8_Release_Notes#Nextcloud and our nextcloud wiki pages. Due to PHP versions, NC21 can not work in mga7 NC20 can not work in mga8 If user neglects to update to NC20 before mga8 he may o Try if it happens to work anyway (jumping to nextcloud 21) o Revert to mga7 and previous Nextcloud and backed up data, then do right o Compile PHP7 https://forums.mageia.org/en/viewtopic.php?f=7&t=14038 and use mga7 nextcloud package or manual install https://wiki.mageia.org/en/Nextcloud#Manually
(In reply to Morgan Leijström from comment #35) > > Due to PHP versions, > NC21 can not work in mga7 > NC20 can not work in mga8 > In fact, NC21 does work in MGA7, as it can work with PHP7.3 and PHP7.4. If some users are still with NC19, they are using an end of life version. According to the implementation of NC with the MGA package, have you disabled the option for the user to update using the Web updater on the admin page? Hence, does it mean we need to be reactive as well to deploy the minor version updates? Honestly, I think it is a good idea to have a package for the 1st installation. For the updates, I would allow the user to do it using the Web updater, making always sure a supported and maintained version is used. Usually, the web updater works well. Of course, c...t might happen, especially if the user has installed "exotic" nexcloud apps. But, in that case, I think it will also break when we'll deploy our updated package. Backup of the database, data and NC is always a must.
(In reply to christian barranco from comment #36) > In fact, NC21 does work in MGA7, as it can work with PHP7.3 and PHP7.4. Thanks for the correction. But it is too late to ship an (official) update for mga7 > If some users are still with NC19, they are using an end of life version. Well we did ship NC20 :) > According to the implementation of NC with the MGA package, have you > disabled the option for the user to update using the Web updater on the > admin page? I dont remember how it was done, but years ago it could not auto update. I did this experiment then: https://wiki.mageia.org/en/OwnCloud#Facilitating_auto_update > Hence, does it mean we need to be reactive as well to deploy the minor > version updates? That is what i dislike about previous packaging. > Honestly, I think it is a good idea to have a package for the 1st > installation. For the updates, I would allow the user to do it using the Web > updater, making always sure a supported and maintained version is used. IMO that is a good idea. If we change to that, we also need to tell existing users how to enable autoupdate. > Usually, the web updater works well. Of course, c...t might happen, > especially if the user has installed "exotic" nexcloud apps. But, in that > case, I think it will also break when we'll deploy our updated package. Ye, that is one reason we ship updates not in updates repo, but instead in backports, so users more actively have to select to update. I have had Nextcloud installs for reason i understand, and for reasons i dont... Nowadays i use a hosted set up instead... > Backup of the database, data and NC is always a must. Absolutely
"I have had Nextcloud installs for reason "... -> "I have had Nextcloud installs *break* for reason "...
Just noting that for recent NC the mysqld sort_buffer_size need be 2M (which also is new MariaDB default) or else there is problem with at least the circles app which IIUC is enabled by default. - all according to https://github.com/nextcloud/circles/issues/789#issuecomment-984497877 Another heads up: note when writing any install instruction: Bug 29830 - drakrpm (but not urpm) pull in the for NC incompatible PHP8.1 from backports if you ask for task-lamp BTW, any progress on packaging NC?
I see Cauldron is keeping up NC version with upstream, already on 23.0.0 How that is packaged regarding structure etc we have discussed I have no idea, I just note that NC packaging have not ceased :) Morgan Leijström from comment #37) > (In reply to christian barranco from comment #36) > > Honestly, I think it is a good idea to have a package for the 1st > > installation. For the updates, I would allow the user to do it using the Web > > updater, making always sure a supported and maintained version is used. > > IMO that is a good idea. > If we change to that, we also need to tell existing users how to enable > autoupdate. > > > Usually, the web updater works well. Of course, c...t might happen, > > especially if the user has installed "exotic" nexcloud apps. I think packaging one of each major version released during Mageia version life is good, and have autoupdate working. One of each major, so new installs of NC in end of Mageia version life do not need to upgrade several steps - error prone. NC have several major releases each Mageia cycle... How to deal with a situation where the user have autoupdated NC to version m+1 on Mageia n, and then update to Mageia n+1 which have lesser NC version in release repo? - Have all NC packages in backports?
I think it's safest for the Mageia nextcloud users to always have all nextcloud packages in backports. That way they are not included when upgrading from one Mageia release to the next. The nextcloud users need full control over which version they use.
i will push 22 in backport ( before 23 ). Can i push 22.2.3 ?
Being backport, i think order does not matter. @Christian, are you working on a redesign, or do we keep this rolling as is? As for testing and using, I am off, just supporting this from the sideline.
Hi I tried some time ago to get the ball rolling on [qa-discuss] and mixed feelings were expressed. Recently, on IRC, someone was looking for support on NC. He was still using an early 21.0.0 from backport_testing of MGA8. This version was not ready for production, especially with PHP8.0 Many security fixes have been pushed also since then. In addition, it looks like he has got PHP8.1 from backport and things got worse. If we provide a package, my view is we need also to update it with the security fixes. Most probably, it means we have to update with each new update in the same branch. I would go even beyond that. Knowing 21 is end of life on 2022-02, my view is we'll have to propose NC22 from that time. If I try to summarize my view: if we offer a package, it should not be via backport, and it should always be up-to-date (in the same branch or moving to a new one when EOL is reached). We could wait for 10 days before updating, to capture any quick bug fix just after the upstream update.
i tend to agree with you after reading your analysis.
There is another end of the version train: some server applications are not always ready when new server gets released, so we must not force server updates (or "trick" users by "hiding" it as a normal update rpm) Complicated. Regardless of EOL we must have upgrade path from previous Mageia. That means NC21.latest.subversion in mga8 backport. Could we skip actually packaging NC and instead have a package with a script that install dependencies, configures things to some known default, and download NC? ...Or just have wiki page describing it like Christian did. ( BTW, the PHP8.1 for that user was probably Bug 29830 - drakrpm autoselects dependencies from a disabled repo, and install them (upgrade applet too?) )
I'll do my best to support NC testing if you pursue this. Be aware, I do prefer the simplicity Mageia offered for prior versions, pretty much seamless and included Apache which I am generally comfortable with. Upgrades have always been hit or miss. If we decide to go with NGINX that is fine, but we should try to automate the install as much as possible. If the user has to do a ton of manual configuration in NGINX probably will frustrate most ... including me.
(In reply to Brian Rockwell from comment #47) > I'll do my best to support NC testing if you pursue this. > > Be aware, I do prefer the simplicity Mageia offered for prior versions, > pretty much seamless and included Apache which I am generally comfortable > with. > > Upgrades have always been hit or miss. > > If we decide to go with NGINX that is fine, but we should try to automate > the install as much as possible. If the user has to do a ton of manual > configuration in NGINX probably will frustrate most ... including me. i plan to add http and nginx subpackage to ease installation.
(In reply to Morgan Leijström from comment #46) > There is another end of the version train: some server applications are not > always ready when new server gets released, so we must not force server > updates (or "trick" users by "hiding" it as a normal update rpm) > > Complicated. > > Regardless of EOL we must have upgrade path from previous Mageia. > That means NC21.latest.subversion in mga8 backport. > > Could we skip actually packaging NC and instead have a package with a script > that install dependencies, configures things to some known default, and > download NC? > > ...Or just have wiki page describing it like Christian did. > > > ( BTW, the PHP8.1 for that user was probably Bug 29830 - drakrpm autoselects > dependencies from a disabled repo, and install them (upgrade applet too?) ) i am against because this won't be idempotent anymore.
Nicolas, i don't understand which part you are against.
the script downloading the tarball, deps, etc. if we do this we loose the idempotent feature of rpm. If something change remotely we won't be able to know why and help our users .
OK. I understand that view too. Comments on that: I believe support for NC itself, and apps, is better from their forum But we should have a defined environment around NC (apache/nginx, database, default configurations...) They should not get updated by NC updates (but it happens they need be changed for new versions). Can we really keep up serving updates? Also point releases - security etc. We have almost always been long behind before - especially last year... At least we should serve some instruction on how to enable self update.
Hi Apps management is indeed a valid point. New versions are also rolled-out gradually. We should not rush to propose it (at least wait for 10 days ; to be discussed). Then, my view is the update will have to follow the manual process described here: https://docs.nextcloud.com/server/latest/admin_manual/maintenance/manual_upgrade.html Meaning: *Before launching the upgrade, we'll have to send a pop-up to the user, recommending to backup data and database. The user will have to accept explicitly to launch the update. *Then, a script will be launched to stop server and NC cron job, to backup the Nextcloud folder, including apps and config.php. Config.php and apps will be restored inside the Nextcloud folder and occ command will be run to complete the update.
I would like to keep it simple. The server already have a function to notify admin when there is a new version released. Admin then check apps for compatibility (server reports that too at ..../index.php/settings/admin/overview), update them, performs backups, and then update NC from backports repo. (OK first admin need to wait for us to package... this part is one reason i like auto update) We can point user to upstream instructions, maybe have it in a wiki page... i once wrote for OwnCloud https://wiki.mageia.org/en/OwnCloud#Backing_up
(In reply to Morgan Leijström from comment #54) > I would like to keep it simple. > > The server already have a function to notify admin when there is a new > version released. > I understand your point. However, I am afraid we have to choose. If we keep track of the version updates, we have to take care of the full update process. If we don't track the version update and we rely on user intervention, why proposing a package? A good and up-to-date wiki will be more appropriate.
Complement: to ease the task, I propose we stick to recommended setup which is Apache and MySQL. PostgreSQL and/or NGINX configuration will be for more advanced users. I am saying that because I have seen heavy change in NGINX configuration file while switching to a new major version. While the Apache configuration was smoothly managed, transparently for the user.
(In reply to christian barranco from comment #56) > Complement: to ease the task, I propose we stick to recommended setup which > is Apache and MySQL. > PostgreSQL and/or NGINX configuration will be for more advanced users. > I am saying that because I have seen heavy change in NGINX configuration > file while switching to a new major version. While the Apache configuration > was smoothly managed, transparently for the user. we can add as now the http configuration files in the main package and provide nginx as a subpackage
Seeing you both proposing this and working toward the solution I am now more confident than before that you will both solve the packaging and keep it updated. Go on :) For advanced users Christian have already made a wiki page :) The new packaging for easy installation will need a new shorter wiki page by itself. (Maybe pick some parts from my old OwnlCoud page, and Christians)
Any progress? To decide for mga9: https://wiki.mageia.org/en/Mageia_9_Release_Notes#Nextcloud And we do not have a packaged path for mga7 -> 8 yet...?
status? I think we soon need a decision for mga9: drop or finish it up.
We had discussed changing the package to set up the structure for nextcloud without actually packaging the software. AFAIK, that hasn't been done. It should be dropped.
Hi all. Sorry for my late reply; too busy right now. I have done some tests s9me time ago, but no time to report it. Here is a summary: *the update MGA7 to MGA8 would not have worked because the last NC version available for MGA7 was not compatible with Php8. The thing is you need to run a PHP script when you update and the script belongs to the NC version you update from. *if there is a package update released, we need to have a script run to backup the current version of NC, copy the conf file and do the update. In all fairness, the stock web updates will do a better work. *if we still have an initial package provided, we need to make sure the version is stable enough. I have seen a user who has installed our package, with a version not mature for production and had never updated it, because we have never proposed an automatic update. Beside stability, it is really an issue not to do the updates as it fixes security breaches. I would recommend to rather spend time on good tuto on our wiki.
Wouldnt it work to update to Nextcloud 21 in mga7 (still php7), before upgrading to mga8 (still Nextcloud 21, now on php8)? Apart from that, I agree to better spend time on wiki.
Blocks: (none) => 30163
Keep this bug open until information is updated: https://wiki.mageia.org/en/Mageia_8_Release_Notes#Nextcloud https://wiki.mageia.org/en/Mageia_9_Release_Notes#Nextcloud https://wiki.mageia.org/en/Nextcloud Or some superpower steps in to fix it and keep it packaged.
Keywords: (none) => FOR_RELEASENOTES8, FOR_RELEASENOTES9
Updated mga8 & 9 release notes, and https://wiki.mageia.org/en/Nextcloud Revert if we really do package Nextcloud in mga8 very soon and keep it updated. I see it is still updated in cauldron, but as said no upgrade path or instruction even from mga7 to 8 yet...
Status comment: (none) => Dropping.Keywords: FOR_RELEASENOTES8, FOR_RELEASENOTES9 => (none)
would be nice to speak with the package maintainer before dropping a package no ? there is no upgrade path using the tarball too as this is how nextcloud works. Using a package will allow us to patch the package to make it work in mageia9 ( with php8.2). Blino confirmed it works. for nextcloud if you really don't want it on release i can push it in backports like for mageia 8
(In reply to Morgan Leijström from comment #63) > Wouldnt it work to update to Nextcloud 21 in mga7 (still php7), before > upgrading to mga8 (still Nextcloud 21, now on php8)? > Yes, it should work. However, it would be only for a user still with MGA7 and installing NC for the first time; as there is not update management with our package. This user would then willing to move to MGA8 only now. Morgan, what do you have in mind more precisely with this proposal?
Hi Sorry I thought there was no interest because of no response last eight months. And there is no package released for mga8. Why no status update, and package for our *current* release...? Also we have failed to inform users how to upgrade from mga7 - by any method - ever since mga8 got released. We could have written it on the Nextcloud page, and update release notes to point at it. Any method is OK, even if it is a reinstall such as making backup, upgrade Mageia, install NC fresh, set up and import backup. Can we write instruction on moving from mga 7 to 8? Package for our current release and keep it updated? Have upgrade working to mga9? - Then I am happy if we dont drop NC :) If you promise above will be executed soonish, i will, or youself can, revert or edit my three wiki changes of today. I guess backport is the correct place. I am not managing a NC instance since long, so I am not very knowledgeable as you other here. I just want to push this a bit.
(In reply to Morgan Leijström from comment #68) > Hi > > Sorry I thought there was no interest because of no response last eight > months. so many bugreports, packages to work on, "shit happens" :-) > And there is no package released for mga8. because we forgot to move it: http://ftp.free.fr/mirrors/mageia.org/distrib/8/SRPMS/core/backports_testing/nextcloud-22.2.3-1.mga8.src.rpm > > Why no status update, and package for our *current* release...? what do you mean ? NC is up to date with the latest release in cauldron. > Also we have failed to inform users how to upgrade from mga7 - by any method > - ever since mga8 got released. We could have written it on the Nextcloud > page, and update release notes to point at it. Any method is OK, even if it > is a reinstall such as making backup, upgrade Mageia, install NC fresh, set > up and import backup. > > Can we write instruction on moving from mga 7 to 8? > > Package for our current release and keep it updated? > > Have upgrade working to mga9? it can't work the way NC is done. > - Then I am happy if we dont drop NC :) > > If you promise above will be executed soonish, i will, or youself can, > revert or edit my three wiki changes of today. > > I guess backport is the correct place. I am not managing a NC instance since > long, so I am not very knowledgeable as you other here. I just want to push > this a bit. the advantage of backport is that it has to be activated so it is a user demand to update.
in fact this bugreport was for backport move and the tons of comments made it out of scope :-( The bugreport is about mageia 8 and you speak about dropping for cauldron. We should stay focus and a new bugreport report mus be created to speak about cauldron. I can update the mga8 package with a newer release maybe it will help.
Yeah, sorry, I thought this looked abandoned already as in mga8 we yet have no packages except for 21 but only in testing. Lets fix up mga8, then we'll see :) I am reverting the wiki pages and packages to drop list. (In reply to Nicolas Lécureuil from comment #69) > (In reply to Morgan Leijström from comment #68) > so many bugreports, packages to work on, "shit happens" :-) I understand. I am impressed by how much you do manage :) > > > And there is no package released for mga8. > > because we forgot to move it: > http://ftp.free.fr/mirrors/mageia.org/distrib/8/SRPMS/core/backports_testing/ > nextcloud-22.2.3-1.mga8.src.rpm Ah, so it is on the way :) I see NC21 is still in testing. Is it ready to move to backports? And after test OK NC22, it is time to package NC23 for mga8, then 24 > > Why no status update, and package for our *current* release...? > > what do you mean ? I mean please report back on this bug so we know what happens :) Or what is intended to happen > NC is up to date with the latest release in cauldron. I meant updated packages in Mageia 8 backports > > Can we write instruction on moving from mga 7 to 8? > > > > Package for our current release and keep it updated? > > > > Have upgrade working to mga9? > > it can't work the way NC is done. We need then to describe manual method (backup, uninstall NC, upgrade Mageia release, reinstall NC?) > the advantage of backport is that it has to be activated so it is a user > demand to update. That is good :)
Status comment: Dropping. => (none)
Blocks: 30163 => (none)
new package pushed into mga8 backport
Great, I see mga8 NC24 built :) I also see in backports_testing versions 21.0.0 and 22.2.3 Now we only miss version 23 to step by step upgrade for old users. It have also happened that some app only work/is available on earlier versions. I also wonder if we maybe should update the 21.0.0 to some later 21.x.y - we used to avoid .0.0 versions due to historical problems. __Idea for upgrade from mga7: 1. on mga7 do step upgrade each major NC until NC20 in backport. 2. backup data and settings files and export database 3. fresh install of mga8 or if upgrade: need NC be uninstalled first? 4. install database software, import database, restore data 5. install NC21 and deps, restore/edit settings files 5+ make sure NC21 runs OK, incl wanted apps, uninstall apps, upgrade to next NC major and apps, test, etc... Correct?
(In reply to Morgan Leijström from comment #73) > I also wonder if we maybe should update the 21.0.0 to some later 21.x.y - we > used to avoid .0.0 versions due to historical problems. But not later date than our 22.2.3, so optimally version 21.0.7. "just" to be safe
Now only version 24 is on my mirror...?
MGA8 has been primary for over a year now and MGA7 has been deprecated at least that long. Once I saw that MGA8 was in without Nextcloud working I moved to other options for Nextcloud server. My suspicion is anyone else with Nextcloud has done the same as our old version is not compatible with the phone app and probably not the desktop client. Is this worth the effort? We failed to provide a path when needed and anyone would have moved on rather than stay on mga7. I'd say we are better off moving to the Nextcloud way of packaging and maintaining the app using their update path moving forward. Thus documenting the process and maybe simplifying things such as Apache config. I've tested using this method and it works btw. Morgan assume at this point there is no path from MGA7 NxtCld 21 to current. That's my opinion, Brian
(In reply to Morgan Leijström from comment #75) > Now only version 24 is on my mirror...? uploading the 24 removed the others from testing. If you want we can rebuild 21 -> validate -> 22 -> validate -> 23 validate -> 24 -> validate
(In reply to Nicolas Lécureuil from comment #77) > uploading the 24 removed the others from testing. > > If you want we can rebuild 21 -> validate -> 22 -> validate -> 23 validate > -> 24 -> validate "Nice to have" even if we may not endure the time to test it. If they are built similarly to 24 and we first just test 24 and it pass, I guess we this time just test they install with deps and then ship them. Probably not many will use them, but it is elegant too provide a probable path. If not too much work of course. --- Regarding old versions Brian have a point or two... Would be nice though to show there is a path and we did not completely drop the ball, we are just late... For future Mageia/php/nextcloud compatibility, Nicolas mentioned one avantage of packaging: (In reply to Nicolas Lécureuil from comment #66) > Using a package will allow us to patch the package to make it work in > mageia9 ( with php8.2).
Personally I would not start patching NC to enforce php compatibility. There might other implications with NC apps we will never be able to test.
Good point.
Status, and plan? What I find: ___Mageia 9___ I see NC24 is in /cauldron/x86_64/media/core/release/. It should be removed per https://bugs.mageia.org/show_bug.cgi?id=30163#c26 & 27 Another reason: we only have PHP8.2 in mga9? Not 8.1? Probably first Nextcloud server to support PHP 8.2 will be NC26 (Some report NC25 works but not fully/reliably/officially; https://github.com/nextcloud/server/issues/32595 ) So... introduce NC in mga9 by version 26 in backports when upstream is ready... History repeats. ___Mageia 8___ My point of view in Comment 78 - if easy to build the intermediate versions from highest point release of next major after what we packaged in mga7, up to last point release of NC25. Optionally later also NC26 if some NC apps still is not compatible with PHP 8.2 when NC26 is released...
Setting it high because it is important to drop it now from mga9 release!
Priority: Normal => High
Summary: Nextcloud 21 backport to work with PHP8 in Mageia 8 => Nextcloud 21..25 in Mageia 8, later 26 (first for PHP8.2) in mga9 - all backports *only*
Hi. Just a comment: according to my tests, downloading a package update is not enough to update the server properly. Would you have another experience? If not, it means there is no need to pay too much attention to package all major versions and keep them. Only one package of a mature release of the latest branch would be enough, in order to propose a first good installation. The updates will have to be done by the user using the web updater on the Nextcloud admin page. To preserve a running server while migrating to a new version of Mageia, the only thing to do is to make sure the landing PHP version is supported by the Nextcloud server version already installed. Mysql or Postgresql version updates should not be an issue.
I have no experience younger then a few years... I am just watching... Our earlier take on this was that the Nextcloud updater should not be used. Maybe stemming from elder times when it often failed, but may also be a security concern? Updater was earlier by default not operational. I tested and wrote: https://wiki.mageia.org/en/OwnCloud#Facilitating_auto_update
Hi Morgan I have been using the web updater for at least 5 years without any issue. However, I don’t update right away when a new version is proposed and never before a x.x.2 release.
Nice web updater works. Is enabled using our current package of NC? So one version per Mageia release could be sufficient, the latest NC point release at Mageia release time could be put in backports. ( Delayed to the first one supporting that PHP version that is :/ ) But there are five or more NC major releases per Mageia release. Say a user late in Mageia release lifetime want to install NC by our package, then user need to do several upgrade runs i.e install NC21 (if we had it at mga8 release), update to 22, 23, 24, 25. (In reply to christian barranco from comment #83) > according to my tests, downloading a package update is not > enough to update the server properly. Another reason to only provide Nextcloud in backport, so the system never updates it. (Minus possibly by Bug 29830) --- Another take on this is as discussed to not package a specific version but maybe just a helper package pulling in deps, maybe creating dirs, etc, end then user should use upstream documented method to download and install current version.
Status comment: (none) => Remove from mga9 core release
as the maintainer, i am for the "backport" solution.
Hi. About php8.2 support work: https://help.nextcloud.com/t/hold-on-php-8-1-after-php8-2-upgrade-yesterday/151893/11 Backport is definitely the good choice. Even if one might argue, this package is more for "non-advanced" users and these users might not look at Backport. The question I had before, though, is why disabling the Web Updater in our package ? What is the expected way a user will update Nextcloud server?
HI Christian, I agree with your thoughts on this. FYI - when I manually built Nextcloud server, I of course enabled the web-updater and thus always have a current server. I think we'd have to default it to the folders Nextcloud wants to use, but it really is the best choice (my opinion). To really make it smooth, we'd need to included the correct http server parameters, I really don't care if it is Apache or Nginx, but whatever it is, it has to work simply. Just thoughts from the peanut gallery, Brian
Using nextcloud web updater may pose a risk of user updating nextcloud to a version not suitable for our PHP version, or some other stuff. If you are security concerned you would lock down even more, like apps. That said I would prefer web updater to work. I think it is better we let users update and get bug fixed and new versions easily. There are anyway more issues than PHP to care about, like app version in compatibility etc... and we do not lock app installing or updating.
Hi Morgan. To face an issue because of php while updating, it would mean our php version is end of life, which is unlikely. Application compatibilities are tested by the updater prior updating and an alert is sent, in such case. By experience, waiting for the 2 revision at least gives time for the app devs to update their apps as well; this time is often required to get enough stability of Nextcloud itself.
So what is the current status in mga8 updates/backport and in mga9 release?
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=31762
(In reply to Nicolas Lécureuil from comment #87) > as the maintainer, i am for the "backport" solution. Still for mga8, nextcloud server have not been packaged in any repo. For mga9 we have 24.0.5 in release, from september - should be updated for release. And I suggest self updating to be enabled, because of our track record.
Status comment: Remove from mga9 core release => (none)Summary: Nextcloud 21..25 in Mageia 8, later 26 (first for PHP8.2) in mga9 - all backports *only* => Nextcloud in Mageia 8? How for mga9?
nextcloud server does not allow skipping versions. urpmi will skip versions if there is more than one available. If a user has a server running, and for any reason there are two new versions in any repo, then urpmi will always select the latest version, breaking nextcloud server. There can be multiple versions if the user is slow at installing updates, or has delayed upgrading from one Mageia release to the next until after support has ended. It's inherently unsafe to provide nextcloud server for Mageia users. What would be ok would be something like "nextcloud-server-prepare" that installs all of the requires and instructs the user how to install the actual nextloud server from nextcloud
Summary: Nextcloud in Mageia 8? How for mga9? => Nextcloud server must not be provided by Mageia.
I actually like that idea of nextcloud-server-prepare. Most of the work is in the prep work not running their install. I found the following documentation useful: https://wiki.mageia.org/en/Nextcloud_server_installation_with_NGINX
(In reply to Brian Rockwell from comment #95) > I actually like that idea of nextcloud-server-prepare. Most of the work is > in the prep work not running their install. > > I found the following documentation useful: > https://wiki.mageia.org/en/Nextcloud_server_installation_with_NGINX I can say I opted to use apache instead of nginx. Note in the middle of the instruuctions is a script to download Nextcloud software that works very very well. <i>The script below will download Nextcloud and will set the proper permissions. Create the file get_nc.sh in your home folder, for instance. </i>
nextcloud-24.0.5-3.mga9.src.rpm must be removed from Mageia 9 core release! It will break nextcloud for anyone upgrading from Mageia 8 if their version is older than nextcloud-23.
Source RPM: (none) => nextcloud-24.0.5-3.mga9.src.rpmVersion: 8 => Cauldron
I believed it is much better to just maintain a good wiki page including a script as text, than to also need to have to sync a packaged script to the wiki descriptions. Can easily go out of sync and be confusing.
Adding sysadmin team to cc list. Please remove nextcloud-24.0.5-3.mga9.src.rpm from Mageia 9 core release before release freeze.
CC: (none) => sysadmin-bugs
Rather then putting a script in the wiki, I recommend adding it as an attachment to a bug report and having a link to that attachment in the wiki. Changing the script just requires attaching a new copy and updating the link in the wiki.
Interesting. I found having the script in the text of the wiki simple and very useful. I'd recommend leaving it there. Why not put nextcloud-24.0.5.3.mga9.src.rpm in backports rather than ripping it out entirely. It works. It was the simplicity of the install in Mageia that got me interested in the functionality and usefulness Nextcloud has.
Like all the config file snippets on the wiki page, I think it is best to also keep scripts as plain text. Users should read through before executing anyway.
Status comment: (none) => TODO: Update rel notes 8&9 and wiki pages.
I will, like in mageia 8, provide nextcloud in the backport media, to allow people that want it in rpm to have it.
removed from release. Done!
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
(In reply to Nicolas Lécureuil from comment #103) > I will, like in mageia 8, provide nextcloud in the backport media, to allow > people that want it in rpm to have it. That do sound good as a parallell alternative, - but I find no NC server in mga8 backport? https://ftp.acc.umu.se/mirror/mageia/distrib/8/x86_64/media/core/backports/ Once this is decided/fixed, I will update release notes and wiki.
because it was on this bugreport.
@Nicolas, I understand you will take as your job to provide NC packages to mga9 backports. Will you also populate mga8 backport now/soon? - And with what versions - all major since mga7-latest-version +1?
Morgan I think we would drown in complexity if we provide 21, 22, 23, and 24 in MGA8. Wouldn't an errata telling folks that they will need to do a fresh install and migrate their data to MGA9. There is no viable migration path from what I can tell, because of the differences in php version requirements, etc. Just my opinion... "the peanut gallery"
Yes I too think we should jump mga8. What about https://wiki.mageia.org/en/Mageia_8_Release_Notes#Nextcloud ? Simply edit in?: UPDATE: Sorry we could not package Nextcloud server for Mageia 8. And keep link to wiki page which we edit to promote the manual method more. And provide a link to migration instructions. Any suggestion of such a link? And also update https://wiki.mageia.org/en/Mageia_9_Release_Notes#Nextcloud @ Nicholas, please in the packaged versions enable self update, or provide easy instruction on how to enable that.
(In reply to Brian Rockwell from comment #101) > Interesting. I found having the script in the text of the wiki simple and > very useful. I'd recommend leaving it there. I have updated many times the wiki since I created it and I would find easier to keep everything at the same location to maintain it. Actually, I have not updated it for some time and I need to do so. A few things have changed in the Nginx conf file. There is also a parameter to adjust in the Mariadb conf file and I don’t remember whether I have noted this. Regarding server update, to upgrade from MGA8 to MGA9, the user will have to have updated to Nextcloud 26 in MGA8. This version is compatible with php 8.2. Then, the MGA version upgrade should not be an issue. However, as usual, data and database backups are a must. Myself, I will do a fresh MGA9 installation and a restore of Nextcloud. I find this cleaner.
Updated mga8 rel note and Nextcloud wiki page. Only nextcloud package in mga8 is 24.0.5-1.mga8 in backports testing, too new to upgrade to from mga7, to old for new install, just forget it. I find no nextcloud server package in any mga9 repo. Good, we may introduce a current version in backports. If so, note, when that happens, in our nextcloud wiki page. *and keep it updated* and/or facilitate self-update. In mga9 rel notes now only a link to our nextcloud wiki page. And IMO we should keep it like that. Users will also find it they search.
Status comment: TODO: Update rel notes 8&9 and wiki pages. => (none)Keywords: FOR_RELEASENOTES8, FOR_RELEASENOTES9 => IN_RELEASENOTES8, IN_RELEASENOTES9