7:51 a.m.
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?
8:13 a.m.
On Tue, Apr 3, 2018 at 1:51 PM, Randy Barlow
<bowlofeggs(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
8:19 a.m.
On 03/04/18 15:13, Peter Robinson wrote:
On Tue, Apr 3, 2018 at 1:51 PM, Randy Barlow
<bowlofeggs(a)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.
--
kind regards,
David Sommerseth
8:36 a.m.
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 ☺
11:38 a.m.
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(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
12:07 p.m.
On Tue, Apr 3, 2018 at 12:39 PM Christian Glombek <c(a)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.
12:44 p.m.
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
1:54 p.m.
Yup, that, essentially.
Some deps that are needed for these versions are already outdated and have newer,
incompatible versions in the Fedora rpm repos.
2 p.m.
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?
2:04 p.m.
On Tue, Apr 3, 2018 at 3:00 PM, Christian Glombek <c(a)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
2:11 p.m.
On Tue, Apr 3, 2018 at 3:01 PM Christian Glombek <c(a)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?
2:25 p.m.
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.
3:40 p.m.
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(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
6:02 p.m.
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
6:36 p.m.
Totally agreed. I'd expect having streams for each major would
somewhat mitigate this.
Adam Williamson <adamwill(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
6:52 p.m.
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
10:07 a.m.
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.
2:27 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6:07 a.m.
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.
8:48 a.m.
2018-04-03 13:11 GMT-06:00 Stephen Gallagher <sgallagh(a)redhat.com>:
On Tue, Apr 3, 2018 at 3:01 PM Christian Glombek <c(a)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.
9:51 a.m.
On 4 April 2018 at 14:48, William Moreno
<williamjmorenor(a)fedoraproject.org> wrote:
2018-04-03 13:11 GMT-06:00 Stephen Gallagher <sgallagh(a)redhat.com>:
>
>
>
> On Tue, Apr 3, 2018 at 3:01 PM Christian Glombek <c(a)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.
10:37 a.m.
2018-04-04 8:51 GMT-06:00 James Hogarth <james.hogarth(a)gmail.com>:
On 4 April 2018 at 14:48, William Moreno
<williamjmorenor(a)fedoraproject.org> wrote:
>
>
> 2018-04-03 13:11 GMT-06:00 Stephen Gallagher <sgallagh(a)redhat.com>:
>>
>>
>>
>> On Tue, Apr 3, 2018 at 3:01 PM Christian Glombek <c(a)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.
10:43 a.m.
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:
https://www.hogarthuk.com/?q=node/17
10:50 a.m.
2018-04-04 9:43 GMT-06:00 Randy Barlow <bowlofeggs(a)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:
https://www.hogarthuk.com/?q=node/17
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.
10:57 a.m.
On Wed, 4 Apr 2018, 16:51 William Moreno, <williamjmorenor(a)fedoraproject.org wrote:
2018-04-04 9:43 GMT-06:00 Randy Barlow <bowlofeggs(a)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:
> https://www.hogarthuk.com/?q=node/17
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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.
12:38 p.m.
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_supp...
for more info.
kevin
3:44 p.m.
On Wed, 4 Apr 2018, 18:39 Kevin Fenzi, <kevin(a)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_supp...
for more info.
kevin
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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 ;)
9:52 a.m.
On 2 May 2018 at 12:11, Marek Greško <mgresko8(a)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.
10:02 a.m.
On 05/02/2018 05:52 PM, James Hogarth wrote:
On 2 May 2018 at 12:11, Marek Greško <mgresko8(a)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/next...
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
10:04 a.m.
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.
12:18 p.m.
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?
--
Tomasz Torcz "God, root, what's the difference?"
xmpp: zdzichubg(a)chrome.pl "God is more forgiving."
12:42 p.m.
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/
--
Signed
Sheogorath
1:43 a.m.
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
5:01 a.m.
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.
--
kind regards,
David Sommerseth
5:15 a.m.
On 4 April 2018 at 11:01, David Sommerseth <dazo(a)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
2:26 p.m.
On Wed, 2018-04-04 at 11:15 +0100, James Hogarth wrote:
On 4 April 2018 at 11:01, David Sommerseth <dazo(a)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
3:49 p.m.
On Wed, 4 Apr 2018, 20:26 Adam Williamson, <adamwill(a)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(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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.
3:58 a.m.
Il 04/04/2018 22:49, James Hogarth ha scritto:
On Wed, 4 Apr 2018, 20:26 Adam Williamson,
<adamwill(a)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(a)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(a)lists.fedoraproject.org
<mailto:devel@lists.fedoraproject.org>
To unsubscribe send an email to
devel-leave(a)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.fedoraproje...
12:35 a.m.
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
2:38 a.m.
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.
5:08 a.m.
On 4 April 2018 at 08:38, Benson Muite <benson_muite(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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 ;)
10:11 a.m.
New subject: Local test VMs (was: Status of OwnCloud/NextCloud)
James Hogarth <james.hogarth(a)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
10:47 a.m.
New subject: Local test VMs
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
10:50 a.m.
New subject: Local test VMs (was: Status of OwnCloud/NextCloud)
On Wed, 4 Apr 2018, 16:11 Tim Landscheidt, <tim(a)tim-landscheidt.de> wrote:
James Hogarth <james.hogarth(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
10:23 a.m.
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 ☺
10:26 a.m.
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.
10:35 a.m.
On Wed, 4 Apr 2018, 16:27 Randy Barlow, <bowlofeggs(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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.
10:55 a.m.
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?
2:32 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
4:19 p.m.
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.
4:24 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2185
days inactive
2214
days old
53 comments
24 participants
participants (24)
-
'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