Greetings!
It seems that OwnCloud and NextCloud might be unmaintained in Fedora. I found that upgrading my F27 box to F28 causes it to be unable to login:
https://bugzilla.redhat.com/show_bug.cgi?id=1562949
There are also CVEs open:
https://bugzilla.redhat.com/show_bug.cgi?id=1472720 https://bugzilla.redhat.com/show_bug.cgi?id=1451238
Additionally, F27 has an issue that prevents the calendar from working unless you downgrade one package to the F26 version:
https://bugzilla.redhat.com/show_bug.cgi?id=1525208
I don't think I have the expertise or time to step in and help, unfortunately, but these issues do seem bad for Fedora's users. If the maintainers no longer have time to maintain them, should we retire them? Is anyone else interested in stepping up to help out?
On Tue, Apr 3, 2018 at 1:51 PM, Randy Barlow bowlofeggs@fedoraproject.org wrote:
Greetings!
It seems that OwnCloud and NextCloud might be unmaintained in Fedora. I found that upgrading my F27 box to F28 causes it to be unable to login:
I think the old maintainer did a blog post about this some time ago, can't seem to find it with a quick search, but I think it was on the planet.
https://bugzilla.redhat.com/show_bug.cgi?id=1562949
There are also CVEs open:
https://bugzilla.redhat.com/show_bug.cgi?id=1472720 https://bugzilla.redhat.com/show_bug.cgi?id=1451238
Additionally, F27 has an issue that prevents the calendar from working unless you downgrade one package to the F26 version:
https://bugzilla.redhat.com/show_bug.cgi?id=1525208
I don't think I have the expertise or time to step in and help, unfortunately, but these issues do seem bad for Fedora's users. If the maintainers no longer have time to maintain them, should we retire them? Is anyone else interested in stepping up to help out? _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On 03/04/18 15:13, Peter Robinson wrote:
On Tue, Apr 3, 2018 at 1:51 PM, Randy Barlow bowlofeggs@fedoraproject.org wrote:
Greetings!
It seems that OwnCloud and NextCloud might be unmaintained in Fedora. I found that upgrading my F27 box to F28 causes it to be unable to login:
I think the old maintainer did a blog post about this some time ago, can't seem to find it with a quick search, but I think it was on the planet.
Here's some traces ... https://twitter.com/hogarthj/status/961300659931926528
Not sure what happened after this.
On 04/03/2018 09:19 AM, David Sommerseth wrote:
Here's some traces ... https://twitter.com/hogarthj/status/961300659931926528
Ah, well it sounds like it's happy news at least ☺
Hello!
I'd be happy to maintain NextCloud! I have already done the packaging work for NC v13 and v13.0.1, and various dependencies. Unfortunately there is no upgrade path from the EOL'd v10 rpm that is in Fedora right now, which seems to be somewhat of a blocker. I'd happily support upgrades from v13 but I have no interest in packaging old versions (I might reconsider if dependency bundling were allowed for these "upgrade path" rpms).
Regards, Chris
Randy Barlow bowlofeggs@fedoraproject.org schrieb am Di., 3. Apr. 2018 um 15:36 Uhr:
On 04/03/2018 09:19 AM, David Sommerseth wrote:
Here's some traces ... https://twitter.com/hogarthj/status/961300659931926528
Ah, well it sounds like it's happy news at least ☺ _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Tue, Apr 3, 2018 at 12:39 PM Christian Glombek c@petersen-glombek.de wrote:
Hello!
I'd be happy to maintain NextCloud! I have already done the packaging work for NC v13 and v13.0.1, and various dependencies. Unfortunately there is no upgrade path from the EOL'd v10 rpm that is in Fedora right now, which seems to be somewhat of a blocker. I'd happily support upgrades from v13 but I have no interest in packaging old versions (I might reconsider if dependency bundling were allowed for these "upgrade path" rpms).
Could you explain more about what you would need to do to clean the upgrade path from v10? I'm not sure what you meant above.
El mar, 03-04-2018 a las 17:07 +0000, Stephen Gallagher escribió:
On Tue, Apr 3, 2018 at 12:39 PM Christian Glombek <c@petersen-glombek .de> wrote:
Hello!
I'd be happy to maintain NextCloud!I have already done the packaging work for NC v13 and v13.0.1, and various dependencies. Unfortunately there is no upgrade path from the EOL'd v10 rpm that is in Fedora right now, which seems to be somewhat of a blocker. I'd happily support upgrades from v13 but I have no interest in packaging old versions (I might reconsider if dependency bundling were allowed for these "upgrade path" rpms).
Could you explain more about what you would need to do to clean the upgrade path from v10? I'm not sure what you meant above.
nextcloud requires that in order to get to nextcloud 13 from 10, you upgrade to 11 then to 12 then finally to 13. you have to run the upgrade process in order to keep things working. they do not support skipping versions Dennis
Yup, that, essentially.
Some deps that are needed for these versions are already outdated and have newer, incompatible versions in the Fedora rpm repos.
I should probably add that the actual updater program has not been shipped in the rpms thus far. Although I'm not sure how this affects major updates, it is leading to problems elsewhere (i.e. people have to uninstall some apps on v13 and re-install them on v13.0.1 for them to work again).
And how many people actually still run NC v10?
On Tue, Apr 3, 2018 at 3:00 PM, Christian Glombek c@petersen-glombek.de wrote:
I should probably add that the actual updater program has not been shipped in the rpms thus far. Although I'm not sure how this affects major updates, it is leading to problems elsewhere (i.e. people have to uninstall some apps on v13 and re-install them on v13.0.1 for them to work again).
And how many people actually still run NC v10?
Well, I have an installation of OwnCloud that I never even migrated to NextCloud in the first place... I wouldn't underestimate the number of people stuck on an older version.
(I'd be happy to remake it from scratch on a new NextCloud installation, though. I figured I would probably have to do that anyway at some point).
Ben Rosser
On Tue, Apr 3, 2018 at 3:01 PM Christian Glombek c@petersen-glombek.de wrote:
I should probably add that the actual updater program has not been shipped in the rpms thus far. Although I'm not sure how this affects major updates, it is leading to problems elsewhere (i.e. people have to uninstall some apps on v13 and re-install them on v13.0.1 for them to work again).
And how many people actually still run NC v10?
Given the current status, I suggest you just ask FESCo to give you permission to release 13.x without supporting upgrades from 10.x and then submit a Magazine article explaining the situation once 13.x is landing. As far as the bundling question; that's actually fair game these days as long as your packages have a virtual `Provides: bundled(packagename) = <version>` in the specfile so if we needed to locate packages for security issues, it can be done. So if you wanted to package the intermediate versions(*) with bundled libs to get people through the upgrade, that's an option too.
(*) As module streams, perhaps?
On 04/03/2018 03:11 PM, Stephen Gallagher wrote:
Given the current status, I suggest you just ask FESCo to give you permission to release 13.x without supporting upgrades from 10.x and then submit a Magazine article explaining the situation once 13.x is landing.
I would support this option. It sounds very difficult to me to offer a way for users to hit all the versions along the way (we'd have to package all of them in parallel, the user would have to manually switch to each along the way and $do_stuff to upgrade to each point, the user would have to *know* they need to do that*, etc.). So out of a list of not-great options (burdensome upgrades, just skip to 13, or retire it) I think it's reasonable enough to just declare bankruptcy.
One question comes to mind though - won't this be a problem in the future too? How can we guarantee that users can keep upgrading to 14, 15, 16, etc. since Fedora doesn't keep in-between updates in the repos? I.e., say Fedora 29 ships with nextcloud 14, and before Fedora 30 comes out say 15 and 16 are released. If we update F29 to 16, 15 will be lost with no upgrade path for the users. Perhaps this is why Stephen suggested using modules, so we could continue to offer the various streams. But there's still a communication problem - the user will have to know they need to do $special_things. Maybe that's just an upstream concern?
* As an OwnCloud user I did not know I needed to upgrade incrementally and avoid skipping releases. If I didn't know that, it's probably safe to assume others don't know.
I'm definitely a fan of modules and streams! I'm also a fan of not having to package v11 and v12 ;)
Recently, I've made some non-code PRs to NextCloud in order to streamline their dependency declarations & mgmt in general (see https://github.com/nextcloud/server/issues/8555 & ref'd PRs). It used to be a bit messy, but with the proposed dependency info file, there should be an easy-to-grasp overview of all deps. I hope (and personally think) this will lift the burden on packagers a bit.
As I am still new to the packagers' group, I would appreciate any advice/help/mentoring on this topic!
Also, if I were appointed to reach out to FESCo and DO all of this, I would still have to defer this task a bit, due to other time-consuming commitments atm. I would really love to see current maintainers James and/or Shawn comment on this, and work together with them!
Randy Barlow bowlofeggs@fedoraproject.org schrieb am Di., 3. Apr. 2018 um 21:25 Uhr:
On 04/03/2018 03:11 PM, Stephen Gallagher wrote:
Given the current status, I suggest you just ask FESCo to give you permission to release 13.x without supporting upgrades from 10.x and then submit a Magazine article explaining the situation once 13.x is landing.
I would support this option. It sounds very difficult to me to offer a way for users to hit all the versions along the way (we'd have to package all of them in parallel, the user would have to manually switch to each along the way and $do_stuff to upgrade to each point, the user would have to *know* they need to do that*, etc.). So out of a list of not-great options (burdensome upgrades, just skip to 13, or retire it) I think it's reasonable enough to just declare bankruptcy.
One question comes to mind though - won't this be a problem in the future too? How can we guarantee that users can keep upgrading to 14, 15, 16, etc. since Fedora doesn't keep in-between updates in the repos? I.e., say Fedora 29 ships with nextcloud 14, and before Fedora 30 comes out say 15 and 16 are released. If we update F29 to 16, 15 will be lost with no upgrade path for the users. Perhaps this is why Stephen suggested using modules, so we could continue to offer the various streams. But there's still a communication problem - the user will have to know they need to do $special_things. Maybe that's just an upstream concern?
- As an OwnCloud user I did not know I needed to upgrade incrementally and avoid skipping releases. If I didn't know that, it's probably safe to assume others don't know.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Tue, 2018-04-03 at 15:25 -0400, Randy Barlow wrote:
One question comes to mind though - won't this be a problem in the future too? How can we guarantee that users can keep upgrading to 14, 15, 16, etc. since Fedora doesn't keep in-between updates in the repos?
When I maintained ownCloud, I just shipped upstream major version bumps as downstream stable updates. I wrote a wiki page explaining that the upstream ownCloud upgrade policy was the reason for doing this. It's still there:
https://fedoraproject.org/wiki/OwnCloud#ownCloud_package_update_policy
Totally agreed. I'd expect having streams for each major would somewhat mitigate this.
Adam Williamson adamwill@fedoraproject.org schrieb am Mi., 4. Apr. 2018 um 01:02 Uhr:
On Tue, 2018-04-03 at 15:25 -0400, Randy Barlow wrote:
One question comes to mind though - won't this be a problem in the future too? How can we guarantee that users can keep upgrading to 14, 15, 16, etc. since Fedora doesn't keep in-between updates in the repos?
When I maintained ownCloud, I just shipped upstream major version bumps as downstream stable updates. I wrote a wiki page explaining that the upstream ownCloud upgrade policy was the reason for doing this. It's still there:
https://fedoraproject.org/wiki/OwnCloud#ownCloud_package_update_policy
Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
I notice upstream offers VM, Docker and Snap downloads prominently, for server.
But they also offer the client as flatpak: https://help.nextcloud.com/t/linux-packages-status/10216
I didn't spend much time looking but was unable to find v10 and v11 VM's as maybe an easy way to upgrade from v10 to v11, and v11 to v12.
Chris Murphy
On 04/03/2018 07:02 PM, Adam Williamson wrote:
On Tue, 2018-04-03 at 15:25 -0400, Randy Barlow wrote:
One question comes to mind though - won't this be a problem in the future too? How can we guarantee that users can keep upgrading to 14, 15, 16, etc. since Fedora doesn't keep in-between updates in the repos?
When I maintained ownCloud, I just shipped upstream major version bumps as downstream stable updates. I wrote a wiki page explaining that the upstream ownCloud upgrade policy was the reason for doing this. It's still there:
https://fedoraproject.org/wiki/OwnCloud#ownCloud_package_update_policy
Hey Adam!
I think that's a reasonable stance to take on the update policy, but it doesn't quite address the specific problem I was getting at. I wasn't so much worried about pushing major updates to our users as I was worried about a user *missing* a major update while it was still in the repos. I probably didn't express this clearly enough, but to expand my example:
Suppose:
0. Fedora 29 ships with NextCloud 14. 1. A user installs NextCloud 14. 2. Fedora 29 gets an update to NextCloud 15. 3. The user from #2 doesn't install this, for whatever reason. 4. Fedora 29 gets an update to NextCloud 16. NextCloud 15 is now no longer available in any repo. 5. The user from #2 now updates from NextCloud 14 to 16, which it sounds like will be a problem.
Perhaps modularity is the answer here. Another suggestion I saw was to put the major version into the package name. So there could be nextcloud14, nextcloud15, and nextcloud16 source packages, but of course this is an extra burden on the maintainer for a package that already seems burdensome to maintain as is.
On Wed, 2018-04-04 at 11:07 -0400, Randy Barlow wrote:
On 04/03/2018 07:02 PM, Adam Williamson wrote:
On Tue, 2018-04-03 at 15:25 -0400, Randy Barlow wrote:
One question comes to mind though - won't this be a problem in the future too? How can we guarantee that users can keep upgrading to 14, 15, 16, etc. since Fedora doesn't keep in-between updates in the repos?
When I maintained ownCloud, I just shipped upstream major version bumps as downstream stable updates. I wrote a wiki page explaining that the upstream ownCloud upgrade policy was the reason for doing this. It's still there:
https://fedoraproject.org/wiki/OwnCloud#ownCloud_package_update_policy
Hey Adam!
I think that's a reasonable stance to take on the update policy, but it doesn't quite address the specific problem I was getting at. I wasn't so much worried about pushing major updates to our users as I was worried about a user *missing* a major update while it was still in the repos. I probably didn't express this clearly enough, but to expand my example:
I used to keep a side repo with builds of each major version around to cover this scenario. Not sure if James does the same. I stopped using *cloud when I stopped maintaining it. Not worth the hassle.
I fully support such major version bumps during one fedora release. Maybe there could be prepared nextcloud 11 and nextcloud 12 packages in several weeks steps, not fully functional, just upgrading database to have consistent upgrade path to version 13 then. Since nextcloud 10 is not working any more I doubt anybody would consider it as a problem.
2018-04-03 13:11 GMT-06:00 Stephen Gallagher sgallagh@redhat.com:
On Tue, Apr 3, 2018 at 3:01 PM Christian Glombek c@petersen-glombek.de wrote:
I should probably add that the actual updater program has not been shipped in the rpms thus far. Although I'm not sure how this affects major updates, it is leading to problems elsewhere (i.e. people have to uninstall some apps on v13 and re-install them on v13.0.1 for them to work again).
And how many people actually still run NC v10?
Given the current status, I suggest you just ask FESCo to give you permission to release 13.x without supporting upgrades from 10.x and then submit a Magazine article explaining the situation once 13.x is landing. As far as the bundling question; that's actually fair game these days as long as your packages have a virtual `Provides: bundled(packagename) = <version>` in the specfile so if we needed to locate packages for security issues, it can be done. So if you wanted to package the intermediate versions(*) with bundled libs to get people through the upgrade, that's an option too.
+1 should be a nice changes for the F29 release.
On 4 April 2018 at 14:48, William Moreno williamjmorenor@fedoraproject.org wrote:
2018-04-03 13:11 GMT-06:00 Stephen Gallagher sgallagh@redhat.com:
On Tue, Apr 3, 2018 at 3:01 PM Christian Glombek c@petersen-glombek.de wrote:
I should probably add that the actual updater program has not been shipped in the rpms thus far. Although I'm not sure how this affects major updates, it is leading to problems elsewhere (i.e. people have to uninstall some apps on v13 and re-install them on v13.0.1 for them to work again).
And how many people actually still run NC v10?
Given the current status, I suggest you just ask FESCo to give you permission to release 13.x without supporting upgrades from 10.x and then submit a Magazine article explaining the situation once 13.x is landing. As far as the bundling question; that's actually fair game these days as long as your packages have a virtual `Provides: bundled(packagename) = <version>` in the specfile so if we needed to locate packages for security issues, it can be done. So if you wanted to package the intermediate versions(*) with bundled libs to get people through the upgrade, that's an option too.
+1 should be a nice changes for the F29 release.
To make it absolutely 100% clear this is totally 100% not going to happen .... no.
Today I've spent time between $realwork getting my ansible plays updated to handle F28 (thanks for dropping python2-* early guys!) and have been in contact with lorbus (thanks for stepping up).
Last bit to debug before I can start testing an update of OC and NC is why my automated setup explodes with:
PHP Fatal error: Declaration of OC\Files\Storage\Local::copyFromStorage(OCP\Files\Storage $sourceStorage, $sourceInternalPath, $targetInternalPath) must be compatible with OC\Files\Storage\Common::copyFromStorage(OCP\Files\Storage $sourceStorage, $sourceInternalPath, $targetInternalPath, $preserveMtime = false) in /usr/share/owncloud/lib/private/Files/Storage/Local.php on line 42",
The roles I use for testing are here: https://github.com/hogarthj/test_vms
I'll be pushing updates as I get fixes there
I'll be adding repos here to start tracking the builds: https://copr.fedorainfracloud.org/coprs/jhogarth/
Again, recognise what you'll be stepping up to, but if you are willing help is very welcome.
2018-04-04 8:51 GMT-06:00 James Hogarth james.hogarth@gmail.com:
On 4 April 2018 at 14:48, William Moreno williamjmorenor@fedoraproject.org wrote:
2018-04-03 13:11 GMT-06:00 Stephen Gallagher sgallagh@redhat.com:
On Tue, Apr 3, 2018 at 3:01 PM Christian Glombek <c@petersen-glombek.de
wrote:
I should probably add that the actual updater program has not been shipped in the rpms thus far. Although I'm not sure how this affects
major
updates, it is leading to problems elsewhere (i.e. people have to
uninstall
some apps on v13 and re-install them on v13.0.1 for them to work
again).
And how many people actually still run NC v10?
Given the current status, I suggest you just ask FESCo to give you permission to release 13.x without supporting upgrades from 10.x and
then
submit a Magazine article explaining the situation once 13.x is
landing. As
far as the bundling question; that's actually fair game these days as
long
as your packages have a virtual `Provides: bundled(packagename) =
<version>`
in the specfile so if we needed to locate packages for security issues,
it
can be done. So if you wanted to package the intermediate versions(*)
with
bundled libs to get people through the upgrade, that's an option too.
+1 should be a nice changes for the F29 release.
To make it absolutely 100% clear this is totally 100% not going to happen .... no.
Today I've spent time between $realwork getting my ansible plays updated to handle F28 (thanks for dropping python2-* early guys!) and have been in contact with lorbus (thanks for stepping up).
Last bit to debug before I can start testing an update of OC and NC is why my automated setup explodes with:
PHP Fatal error: Declaration of OC\Files\Storage\Local::copyFromStorage(OCP\Files\Storage $sourceStorage, $sourceInternalPath, $targetInternalPath) must be compatible with OC\Files\Storage\Common::copyFromStorage(OCP\Files\Storage $sourceStorage, $sourceInternalPath, $targetInternalPath, $preserveMtime = false) in /usr/share/owncloud/lib/private/Files/Storage/Local.php on line 42",
The roles I use for testing are here: https://github.com/hogarthj/test_vms
I'll be pushing updates as I get fixes there
I'll be adding repos here to start tracking the builds: https://copr.fedorainfracloud.org/coprs/jhogarth/
Again, recognise what you'll be stepping up to, but if you are willing help is very welcome.
I do understand that mantain a package like OC and NC it is a lot of work, I know it is just a litle help in the path to get the update working but I did some review of missing depencies because was the only visible step to help to get the updated version of NC at that moment, but I am curios about somethings:
1. There is both OC and NC in repos, two packages, the double of works, It is irrational to keep just with one stream of the software? A well documented setp can help users to move from OC to NC.
2. There is some work done to get NC 13 on Fedora, I apreciate that you want to provide a clean path to current users to update, but it is irratational to thing in ship the last version of NC to users and have a very good docs about it?
I see that you have problems with testing the update, is that ansible playbook available in some public repo? I can help to test, a NC/OC test day with a wiki with the test coverage can be a great way to get help in this and get feedback/help for users and I can help to test.
On 04/04/2018 11:37 AM, William Moreno wrote:
A well documented setp can help users to move from OC to NC.
James actually wrote a nice blog post about migration:
2018-04-04 9:43 GMT-06:00 Randy Barlow bowlofeggs@fedoraproject.org:
On 04/04/2018 11:37 AM, William Moreno wrote:
A well documented setp can help users to move from OC to NC.
James actually wrote a nice blog post about migration:
James are you ok with the idea to keep just NC in Fedora? I there is people than still want OC maybe then can take care or maintain it.
On Wed, 4 Apr 2018, 16:51 William Moreno, williamjmorenor@fedoraproject.org wrote:
2018-04-04 9:43 GMT-06:00 Randy Barlow bowlofeggs@fedoraproject.org:
On 04/04/2018 11:37 AM, William Moreno wrote:
A well documented setp can help users to move from OC to NC.
James actually wrote a nice blog post about migration:
James are you ok with the idea to keep just NC in Fedora? I there is people than still want OC maybe then can take care or maintain it. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
We'll see
Let's get both updated and then we can decide from there.
I will provide a migration path though... that is absolutely critical to my commitment to the users to not actively break things or leave anyone stranded.
If I get continuing help once we're caught up it'll be much easier to keep both updated.
For those that want to leap ahead, there will be COPR repos to do so... and that will simplify the updates needed in fedora itself.
On 04/04/2018 07:51 AM, James Hogarth wrote: ...snip...
Today I've spent time between $realwork getting my ansible plays updated to handle F28 (thanks for dropping python2-* early guys!) and have been in contact with lorbus (thanks for stepping up).
Note that if you mean ansible dropping python2 in F28, thats not the case. If you mean some other package dropping pyhon2 that an ansible module you use needs you can set ansible to use python3 for that target.
If you want ansible to use python3 on the control host in f28, you can just install ansible-python3 (in f29+ it will default to python3).
For targets, set ansible_python_interpreter to which you want to use. See http://docs.ansible.com/ansible/latest/reference_appendices/python_3_support... for more info.
kevin
On Wed, 4 Apr 2018, 18:39 Kevin Fenzi, kevin@scrye.com wrote:
On 04/04/2018 07:51 AM, James Hogarth wrote: ...snip...
Today I've spent time between $realwork getting my ansible plays updated to handle F28 (thanks for dropping python2-* early guys!) and have been in contact with lorbus (thanks for stepping up).
Note that if you mean ansible dropping python2 in F28, thats not the case. If you mean some other package dropping pyhon2 that an ansible module you use needs you can set ansible to use python3 for that target.
If you want ansible to use python3 on the control host in f28, you can just install ansible-python3 (in f29+ it will default to python3).
For targets, set ansible_python_interpreter to which you want to use. See
http://docs.ansible.com/ansible/latest/reference_appendices/python_3_support... for more info.
kevin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Don't worry I'm well abreast of the plans and know the magic things to switch.
Had to turn all my python library package installs into variables to override on fedora since this is a massive divergent point with RHEL and python package naming...
Had a python-psycopg2 change bite me too (unencrypted password no longer supported in it which breaks my postgres_user task... but not related to py3) ...
It's only a minor grumble though as these are changes that had to happen soon anyway... but they slow my iterations down to get the oC/nC stuff tested as I have to deal with them first of course.
10pm and eating dinner... when I'm done with that it'll be Netflix and hacking away on this in bed ;)
On 2 May 2018 at 12:11, Marek Greško mgresko8@gmail.com wrote:
Randy, it is the same with nextcloud.
To keep people up to date ...
I figured I'd do owncloud first as that looked a simple single version jump ...
There was much pain that ensued trying to maintain the unbundling of the PHP libraries as upstream have completely commingled the third party libraries with their own code and it all uses the same composer-loader ...
Several hours of trying to patch in the Fedora PHP autoloader and extracting vendor libraries from upstream code and still massive stacktraces of weird behaviour ...
Then my laptop went boom with disk failure ... I'm sure this was a mere coincidence and not the poor Acer refusing to be abused any more ;)
New laptop purchased last weekend and based on the pain from before, at least for the time being, I'm going to remove all the unbundling... at least for the time being.
I'm obviously not going to push something that just goes boom ... so depending on how testing goes in the next few days there will be updates but I just commit to when.
If there is a clean PR that updates to just the next major version in owncloud/nextcloud I will happily merge that ... do note that to comply with guidelines we will need provides: bundled(foo) in the spec
So far, despite this long thread, there has still been no actual assistance with these builds so I'll get to this when I'm able of course.
On 05/02/2018 05:52 PM, James Hogarth wrote:
On 2 May 2018 at 12:11, Marek Greško mgresko8@gmail.com wrote:
Randy, it is the same with nextcloud.
To keep people up to date ...
I figured I'd do owncloud first as that looked a simple single version jump ...
There was much pain that ensued trying to maintain the unbundling of the PHP libraries as upstream have completely commingled the third party libraries with their own code and it all uses the same composer-loader ...
Several hours of trying to patch in the Fedora PHP autoloader and extracting vendor libraries from upstream code and still massive stacktraces of weird behaviour ...
Then my laptop went boom with disk failure ... I'm sure this was a mere coincidence and not the poor Acer refusing to be abused any more ;)
New laptop purchased last weekend and based on the pain from before, at least for the time being, I'm going to remove all the unbundling... at least for the time being.
I'm obviously not going to push something that just goes boom ... so depending on how testing goes in the next few days there will be updates but I just commit to when.
If there is a clean PR that updates to just the next major version in owncloud/nextcloud I will happily merge that ... do note that to comply with guidelines we will need provides: bundled(foo) in the spec
So far, despite this long thread, there has still been no actual assistance with these builds so I'll get to this when I'm able of course.
Thanks. Hoping to help but work is quite heavy. Openbuild service has this (though currently missing a php dependency):
https://build.opensuse.org/package/view_file/server:php:applications/nextclo...
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Looking at Nextcloud releases, it seems that they do a major release once a year.
It should be possible to catch up with the upstream even if there is a single update per Fedora release.
Update to Nextcloud 11 in Fedora 27, 12 in current Fedora 28 and then in Fedora 29 cath up with upstream.
Admittedly that will be a lot of work, but it keeps instances upgradeable.
On Wed, May 02, 2018 at 04:04:11PM +0100, Naheem Zaffar wrote:
Looking at Nextcloud releases, it seems that they do a major release once a year.
It should be possible to catch up with the upstream even if there is a single update per Fedora release.
Update to Nextcloud 11 in Fedora 27, 12 in current Fedora 28 and then in Fedora 29 cath up with upstream.
What about updates (security fixes)? I don't know Nextcloud policy, but each Fedora version is supported for about 13 months. Is it likely to receive security fixes for not-the-latest Nextcloud version?
On 05/02/2018 07:18 PM, Tomasz Torcz wrote:
On Wed, May 02, 2018 at 04:04:11PM +0100, Naheem Zaffar wrote:
Looking at Nextcloud releases, it seems that they do a major release once a year.
It should be possible to catch up with the upstream even if there is a single update per Fedora release.
Update to Nextcloud 11 in Fedora 27, 12 in current Fedora 28 and then in Fedora 29 cath up with upstream.
What about updates (security fixes)? I don't know Nextcloud policy, but each Fedora version is supported for about 13 months. Is it likely to receive security fixes for not-the-latest Nextcloud version?
According to their web page[1] they support the last two versions of Nextcloud. So with ~1 release per year and Fedora with 13 month of support, we are covered here.
[1]: https://nextcloud.com/security/
On Tue, 2018-04-03 at 19:00 +0000, Christian Glombek wrote:
And how many people actually still run NC v10?
FWIW, I have a nextcloud 10 setup on a Fedora 27 server.
I have no problems with major version updates within a Fedora release, but my expectation was that Fedora was keeping it updated.
If I have to jump through some hoops to upgrade from 10 to 13, that's not a problem.
Jonathan
On 03/04/18 21:00, Christian Glombek wrote:
I should probably add that the actual updater program has not been shipped in the rpms thus far. Although I'm not sure how this affects major updates, it is leading to problems elsewhere (i.e. people have to uninstall some apps on v13 and re-install them on v13.0.1 for them to work again).
And how many people actually still run NC v10?
I have two servers with NC v10 via EPEL 7 ... and getting increasingly concerned.
I've even started considering moving those servers over to a stable Debian release, as that environment is closer to EPEL stability than Fedora but with newer dependencies. But I'm not too happy about manually installing NC.
NC is great in so many ways, but the poor packaging means I'll have to rethink how much longer I'm willing to accept the current situation. Time is scarce for everyone.
I don't mean to shoot any of the NC package maintainers in Fedora, I have the impression they have and are doing what they can, as this is a community project. But I think Nextcloud as a company should take this matter far more serious. It might even be considered a business model for a subscription service.
On 4 April 2018 at 11:01, David Sommerseth dazo@eurephia.org wrote:
On 03/04/18 21:00, Christian Glombek wrote:
I should probably add that the actual updater program has not been shipped in the rpms thus far. Although I'm not sure how this affects major updates, it is leading to problems elsewhere (i.e. people have to uninstall some apps on v13 and re-install them on v13.0.1 for them to work again).
And how many people actually still run NC v10?
I have two servers with NC v10 via EPEL 7 ... and getting increasingly concerned.
EPEL can't be updated and both owncloud and nextcloud upstreams are (understandably) hostile to the old PHP version in EL7 ...
The EPEL policies forbid us from using SCL to get a newer PHP as well.
EPEL will be retired as soon as I've pushed an update with an EOL notice - there is no upgrade path for EPEL packages.
If you are running owncloud/nexcloud on CentOS then you either need to use their upstream packages or a container.
Once I've got OC/NC back up to date I'll push on with the "official" Fedora container for them again.
This article will be critical for you in migrating your install to get a current PHP on that EL7 system: https://www.hogarthuk.com/?q=node/15
On Wed, 2018-04-04 at 11:15 +0100, James Hogarth wrote:
On 4 April 2018 at 11:01, David Sommerseth dazo@eurephia.org wrote:
On 03/04/18 21:00, Christian Glombek wrote:
I should probably add that the actual updater program has not been shipped in the rpms thus far. Although I'm not sure how this affects major updates, it is leading to problems elsewhere (i.e. people have to uninstall some apps on v13 and re-install them on v13.0.1 for them to work again).
And how many people actually still run NC v10?
I have two servers with NC v10 via EPEL 7 ... and getting increasingly concerned.
EPEL can't be updated
I think I used to just update it anyway. No-one shot me. :P
On Wed, 4 Apr 2018, 20:26 Adam Williamson, adamwill@fedoraproject.org wrote:
On Wed, 2018-04-04 at 11:15 +0100, James Hogarth wrote:
On 4 April 2018 at 11:01, David Sommerseth dazo@eurephia.org wrote:
On 03/04/18 21:00, Christian Glombek wrote:
I should probably add that the actual updater program has not been
shipped in the rpms thus far. Although I'm not sure how this affects major updates, it is leading to problems elsewhere (i.e. people have to uninstall some apps on v13 and re-install them on v13.0.1 for them to work again).
And how many people actually still run NC v10?
I have two servers with NC v10 via EPEL 7 ... and getting increasingly
concerned.
EPEL can't be updated
I think I used to just update it anyway. No-one shot me. :P
Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Haha... you of all people know what steps I took and lengths I went through to safely update our owncloud users in EPEL when I took over maintenance from you ,)
The reason I said it can't be updated is that EL7 ships with PHP5.4 which has been dropped from support by both owncloud and nextcloud upstream... and they have no intention of changing that with SCL, RemiRepo and IUS as options for their users on their packages.
But of course we can't use any of those for EPEL packages as per our own policies so it literally can't be updated... there's no choice but to retire it.
Il 04/04/2018 22:49, James Hogarth ha scritto:
On Wed, 4 Apr 2018, 20:26 Adam Williamson, <adamwill@fedoraproject.org mailto:adamwill@fedoraproject.org> wrote:
On Wed, 2018-04-04 at 11:15 +0100, James Hogarth wrote: > On 4 April 2018 at 11:01, David Sommerseth <dazo@eurephia.org <mailto:dazo@eurephia.org>> wrote: > > On 03/04/18 21:00, Christian Glombek wrote: > > > I should probably add that the actual updater program has not been shipped in the rpms thus far. Although I'm not sure how this affects major updates, it is leading to problems elsewhere (i.e. people have to uninstall some apps on v13 and re-install them on v13.0.1 for them to work again). > > > > > > And how many people actually still run NC v10? > > > > I have two servers with NC v10 via EPEL 7 ... and getting increasingly concerned. > > > > EPEL can't be updated I think I used to just update it anyway. No-one shot me. :P -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org> To unsubscribe send an email to devel-leave@lists.fedoraproject.org <mailto:devel-leave@lists.fedoraproject.org>Haha... you of all people know what steps I took and lengths I went through to safely update our owncloud users in EPEL when I took over maintenance from you ,)
The reason I said it can't be updated is that EL7 ships with PHP5.4 which has been dropped from support by both owncloud and nextcloud upstream... and they have no intention of changing that with SCL, RemiRepo and IUS as options for their users on their packages.
But of course we can't use any of those for EPEL packages as per our own policies so it literally can't be updated... there's no choice but to retire it.
I just started a discussion on php-devel mailing list, concerning PHP version 7 on EPEL7 branch https://lists.fedoraproject.org/archives/list/php-devel@lists.fedoraproject....
Le 03/04/2018 à 19:44, Dennis Gilmore a écrit :
El mar, 03-04-2018 a las 17:07 +0000, Stephen Gallagher escribió:
On Tue, Apr 3, 2018 at 12:39 PM Christian Glombek <c@petersen-glombek .de> wrote:
Hello!
I'd be happy to maintain NextCloud!I have already done the packaging work for NC v13 and v13.0.1, and various dependencies. Unfortunately there is no upgrade path from the EOL'd v10 rpm that is in Fedora right now, which seems to be somewhat of a blocker. I'd happily support upgrades from v13 but I have no interest in packaging old versions (I might reconsider if dependency bundling were allowed for these "upgrade path" rpms).
Could you explain more about what you would need to do to clean the upgrade path from v10? I'm not sure what you meant above.
nextcloud requires that in order to get to nextcloud 13 from 10, you upgrade to 11 then to 12 then finally to 13. you have to run the upgrade process in order to keep things working. they do not support skipping versions Dennis
So, I don't think we can update the package from 10 to 13, thus breaking all user installations.
I see 2 possible way
The classical one
- create nextcloud11, nextcloud12 and nextcloud13 packages and also future versions, older can be removed when EOLed by upstream (so nextcloud + nextcloud10 removed in F29)
The new one (F28+)
- create a nextcloud module with 1 stream per version, following upstream life cycle
Remi
So, I don't think we can update the package from 10 to 13, thus breaking all user installations.
I see 2 possible way
The classical one
- create nextcloud11, nextcloud12 and nextcloud13 packages and also
future versions, older can be removed when EOLed by upstream (so nextcloud + nextcloud10 removed in F29)
The new one (F28+)
- create a nextcloud module with 1 stream per version, following
upstream life cycle
Remi
First one seems a little easier, but modules look very promising. Any experience testing this? If no next cloud apps are installed, mostly a matter of changing location of data folder. If some Nextcloud apps are installed, this is more difficult since apps do not always get updated.
On 4 April 2018 at 08:38, Benson Muite benson_muite@emailplus.org wrote:
So, I don't think we can update the package from 10 to 13, thus breaking all user installations.
I see 2 possible way
The classical one
- create nextcloud11, nextcloud12 and nextcloud13 packages and also
future versions, older can be removed when EOLed by upstream (so nextcloud + nextcloud10 removed in F29)
The new one (F28+)
- create a nextcloud module with 1 stream per version, following
upstream life cycle
Remi
First one seems a little easier, but modules look very promising. Any experience testing this? If no next cloud apps are installed, mostly a matter of changing location of data folder. If some Nextcloud apps are installed, this is more difficult since apps do not always get updated.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
*COUGH*
How about emailing me and asking what you can do to help?
I've really had no help on this (outside of Shawn and Remi getting dependencies packaged on occasion) since I took this over from AdamW way back.
There's always lots of noise about "oh no OC isn't getting updates" but never any actual help, or even empty offers for help usually.
Honestly I'm tempted to just orphan both owncloud and nextcloud as it's painful to maintain and it's a truly thankless task.
Last time this came up I wrote this on the magazine ... for those who actually have genuine intent to help it's worth reading again: https://fedoramagazine.org/day-life-fedora-packager/
I have no problem with doing major updates in a release, but we do have to manage them carefully to avoid breakage.
As for why it's fallen behind in recent times .... life has a tendency to get in the way. Remember well that most of us (especially me) is not paid for this and try to do our best amongst other things.
I had a new daughter born in January, I also have a daughter who recently turned 2.
I am a DevOps contractor and work has to come first to pay the bills.
My day usually starts at around 6am when I get up, get ready for work, check on the girls and have my ~1.5 hour commute to my office.
I usually get in around 08:30 and work till around 17:00 or so.
My commute back is also around 1.5 hours.
During the commutes I try and catch up on the news and mailing lists.
When I get home it's a short time to dinner, a short playtime with my eldest and then putting her to bed. That will normally take me to about 20:00 or thereabouts.
Then there's general chores and suddenly it's pushing 22:00 with a 06:00 alarm waiting again ...
That is my weekday on a day to day basis ...
My ability to do anything Fedora related during working hours will vary with the contract I have at the time ... my last contract was a clearance-required environment that prevented any such activity.
My present contract gives me a little more freedom, and this is now at the top of my "spare seconds" radar ... indeed I started testing yesterday (without seeing this thread yet).
FIrst thing when I fired up my test harness was that F28 has changed, and thus broken, kickstart for the user option compared to a standard minimal that worked going back to F22 and EL7 so that had to be debugged and fixed ... done
Next things is the ansible that I use to test ... well the lovely folks jumping the gun on dropping python2-* packages is making life painful since ansible still uses python2 by default and not everything support python3 yet. There is no python2-firewall anymore for the ansible firewalld module ... yay another silly thing to work around!
If there is genuine intent to actually help and not just whine then please do contact me directly - I'm frequently on IRC during the working day (UK time) now as well.
My plan is to get the next major versions of both owncloud and nextcloud that are safe to upgrade to built and pushed as soon as I can ... I will bundle libraries if there are versioning issues getting this sorted.
This will also involve a change from mod_php to php-fpm for httpd users, nginx of course already has php-fpm.
When those have been out a few weeks in stable then I'll do the same with the next major release and so on until we are caught up.
At that point I'll look to removing any bundling if some was required.
If this looks like too long a path for you feel free to stop using the packages and just use upstream.
Again, if you are genuine about wanting to help please contact me directly.
If you want to just whine ... well frankly I'm not going to pay any attention to that and we'll get there when we do.
If you want to pay me to maintain these so I can make up lost costs when I'm not working that would also be a plan ;)
James Hogarth james.hogarth@gmail.com wrote:
[…]
FIrst thing when I fired up my test harness was that F28 has changed, and thus broken, kickstart for the user option compared to a standard minimal that worked going back to F22 and EL7 so that had to be debugged and fixed ... done
Next things is the ansible that I use to test ... well the lovely folks jumping the gun on dropping python2-* packages is making life painful since ansible still uses python2 by default and not everything support python3 yet. There is no python2-firewall anymore for the ansible firewalld module ... yay another silly thing to work around!
[…]
BTW, it would be very nice if there was (maintained) docu- mentation on how to generate Fedora VMs and for example use Ansible to configure complex interactive test setups. James's article (https://fedoramagazine.org/day-life-fedora-packager/) is mouth-watering, but lacking detail and probably outdated by now.
I'm sure that many Fedora packagers have their own ("obvi- ous") solutions, but having something general could lower the bar for new packagers who do not want to dive deep into all the minutiae just to test a release.
Tim
On 04/04/2018 05:11 PM, Tim Landscheidt wrote:
BTW, it would be very nice if there was (maintained) docu- mentation on how to generate Fedora VMs and for example use Ansible to configure complex interactive test setups. James's article (https://fedoramagazine.org/day-life-fedora-packager/) is mouth-watering, but lacking detail and probably outdated by now.
It turns out there is such a way! It even uses Ansible. :)
There's a fairly recent Fedora Magazine Article about CI:
https://fedoramagazine.org/continuous-integration-fedora/
I'm sure that many Fedora packagers have their own ("obvi- ous") solutions, but having something general could lower the bar for new packagers who do not want to dive deep into all the minutiae just to test a release.
We started setting up the Standard Test Interface in Fedora to support a lot of the existing "obvious" solutions and provide best practice implementations and support for a lot of things that packagers may want the infrastructure to handle:
https://fedoraproject.org/wiki/CI
Our pipeline to run tests for all packages (non Atomic) should be in production soon, in a matter of weeks. Until then, it's still fairly straight forward to test a package locally.
I invite you to take a look at the material and reach out to us on IRC (contact info on the linked page, #fedora-ci on freenode or via mailing list) with questions.
Thank you Dominik
On Wed, 4 Apr 2018, 16:11 Tim Landscheidt, tim@tim-landscheidt.de wrote:
James Hogarth james.hogarth@gmail.com wrote:
[…]
FIrst thing when I fired up my test harness was that F28 has changed, and thus broken, kickstart for the user option compared to a standard minimal that worked going back to F22 and EL7 so that had to be debugged and fixed ... done
Next things is the ansible that I use to test ... well the lovely folks jumping the gun on dropping python2-* packages is making life painful since ansible still uses python2 by default and not everything support python3 yet. There is no python2-firewall anymore for the ansible firewalld module ... yay another silly thing to work around!
[…]
BTW, it would be very nice if there was (maintained) docu- mentation on how to generate Fedora VMs and for example use Ansible to configure complex interactive test setups. James's article (https://fedoramagazine.org/day-life-fedora-packager/) is mouth-watering, but lacking detail and probably outdated by now.
I'm sure that many Fedora packagers have their own ("obvi- ous") solutions, but having something general could lower the bar for new packagers who do not want to dive deep into all the minutiae just to test a release.
Tim _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Would it surprise you to know that it is actually still valid and not really outdated? ;)
If you'd like me to write something more detailed I'd be happy to do so... after we have oC/nC updated ;)
There is a bunch of relevant material on my blog you may be interested in though that goes into more detail on the process of the test environment... but didn't feel relevant for the magazine...
Start with building of rpms:
https://www.hogarthuk.com/?q=node/11
Then move on to configuring your system for dynamic ansible inventory of libvirt guests:
https://www.hogarthuk.com/?q=node/12
This one covers my vmcreate (to make a new guest entirely), vmprep (to prepare a template for cloning) and vmclone (guess what this does? ) scripts to make generating test instances easier...
https://www.hogarthuk.com/?q=node/13
This reminds me I really need to finish and publish my pending stuff... sudo mktime?
Feel free to contact me about any of this or the scripts I have on github if you want to build something
On 04/04/2018 06:08 AM, James Hogarth wrote:
How about emailing me and asking what you can do to help?
I've really had no help on this (outside of Shawn and Remi getting dependencies packaged on occasion) since I took this over from AdamW way back.
There's always lots of noise about "oh no OC isn't getting updates" but never any actual help, or even empty offers for help usually.
Hi James!
I hope my post didn't sound like complaining to you - that wasn't my intent. My goal was to call attention to the problems in F28 (and F27 has issues to a lesser but still important extent) and to ask if anyone in the Fedora community can help. I really didn't intend to point fingers or place blame - I mean, you can certainly find lots of open tickets assigned to me that I haven't gotten to either.
I also wanted to call attention to it before F28 stabilizes, because the current issues are pretty severe and I wanted to make sure Fedora takes some action before our users are affected (even if the action is to remove it from Fedora).
My knowledge about PHP is pretty limited, and like you I also have a pretty full schedule and two large applications that I maintain, so I personally can't commit to help with this due to the combination of those two factors.
Honestly I'm tempted to just orphan both owncloud and nextcloud as it's painful to maintain and it's a truly thankless task.
I think this would be OK if you want to do that route, but it does sound like there are some volunteers who would be willing to get involved.
I really appreciate the work you did to get us this far, so thank you for your contributions, and also congratulations on the new addition to your family ☺
Another thought on this topic:
It's probably a lot of work to maintain OwnCloud and NextCloud, and it sounds like a lot of people have moved to NextCloud or intend to in the future. Would it help if we went ahead and retired OwnCloud so we could focus on just one of the two to reduce the burden?
I'm in the "I use OwnCloud but intend to switch to NextCloud" camp myself.
If there are OwnCloud users who do not want to switch to NextCloud, perhaps they could step in to maintain OwnCloud.
On Wed, 4 Apr 2018, 16:27 Randy Barlow, bowlofeggs@fedoraproject.org wrote:
Another thought on this topic:
It's probably a lot of work to maintain OwnCloud and NextCloud, and it sounds like a lot of people have moved to NextCloud or intend to in the future. Would it help if we went ahead and retired OwnCloud so we could focus on just one of the two to reduce the burden?
I'm in the "I use OwnCloud but intend to switch to NextCloud" camp myself.
If there are OwnCloud users who do not want to switch to NextCloud, perhaps they could step in to maintain OwnCloud. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
To quote you... "I use Owncloud but intend to switch to nextcloud"
That intent goes all the way back to my blog post on how to migrate and writing up the tested documentation to do so...
But there's nothing I do or need on there that actually requires migration... so it hasn't happened yet.
Il 04/04/2018 17:26, Randy Barlow ha scritto:
Another thought on this topic:
It's probably a lot of work to maintain OwnCloud and NextCloud, and it sounds like a lot of people have moved to NextCloud or intend to in the future. Would it help if we went ahead and retired OwnCloud so we could focus on just one of the two to reduce the burden?
I'm in the "I use OwnCloud but intend to switch to NextCloud" camp myself.
If there are OwnCloud users who do not want to switch to NextCloud, perhaps they could step in to maintain OwnCloud. _______________________________________________
I never used OC or NC, so here are my two cents: both are painful to package in Fedora, so why don't we ask upstream to make some changes that would simplify our work (if there are any)?
If one of them can work with us to get their software well supported in Fedora, then we should choose and focus on that software.
If both are not willing to help us in our packaging effort, simply choose one of them and drop the other. I can see OC provides their own Fedora repository, so why bother?
On Wed, 2018-04-04 at 17:55 +0200, Mattia Verga wrote:
Il 04/04/2018 17:26, Randy Barlow ha scritto:
Another thought on this topic:
It's probably a lot of work to maintain OwnCloud and NextCloud, and it sounds like a lot of people have moved to NextCloud or intend to in the future. Would it help if we went ahead and retired OwnCloud so we could focus on just one of the two to reduce the burden?
I'm in the "I use OwnCloud but intend to switch to NextCloud" camp myself.
If there are OwnCloud users who do not want to switch to NextCloud, perhaps they could step in to maintain OwnCloud. _______________________________________________
I never used OC or NC, so here are my two cents: both are painful to package in Fedora, so why don't we ask upstream to make some changes that would simplify our work (if there are any)?
They don't want to. They (especially OC) are excessively uninterested in aiding downstream packaging, think it's a waste of time, and advise people to use their upstream deployment methods at every opportunity. This was one major factor in me abandoning efforts to package OC.
i remember OC being very protective of their stream and not working well with others to get it in other distributions. I was an oC user that switch to nC and still running V10. I've been waiting for an update to nC and would like to stay with it even if i have to upgrade though 11 and 12 to get to 13. Is there another package out there that does what oC/nC does that would be a bettter fit for fedora? i'd consider a migration to different product that does the same thing if it is easier to maintain.
On Tue, 2018-05-01 at 21:19 +0000, mark preston wrote:
i remember OC being very protective of their stream and not working well with others to get it in other distributions. I was an oC user that switch to nC and still running V10. I've been waiting for an update to nC and would like to stay with it even if i have to upgrade though 11 and 12 to get to 13. Is there another package out there that does what oC/nC does that would be a bettter fit for fedora? i'd consider a migration to different product that does the same thing if it is easier to maintain.
OC/NC sort of gloms a *lot* of different jobs together, which is one reason the code is kind of a nightmare. So there aren't really many alternatives to "everything OC/NC does" (Kolab may be the closest). But most people don't actually use "everything", I don't think, just certain bits. So the answer is: it depends what bits of OC/NC you actually rely on, what goals does it help you accomplish?
Personally, I replaced my use of OC/NC with a webdav share configured directly in Apache, and Radicale (dnf install radicale) to replace the shared calendar/todo list. But if you use OC/NC for different things, your 'replacement' may differ.
-
'Dominik Perpeet' -
Adam Williamson -
Ben Rosser -
Benson Muite -
Chris Murphy -
Christian Glombek -
David Sommerseth -
Dennis Gilmore -
Germano Massullo -
James Hogarth -
Jonathan Dieter -
Kevin Fenzi -
Marek Greško -
mark preston -
Mattia Verga -
Naheem Zaffar -
Peter Robinson -
Randy Barlow -
Remi Collet -
Sheogorath -
Stephen Gallagher -
Tim Landscheidt -
Tomasz Torcz -
William Moreno