Re: Status of OwnCloud/NextCloud

2018-05-02 Thread Sheogorath
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



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-05-02 Thread Tomasz Torcz
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: zdzich...@chrome.pl "God is more forgiving."
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-05-02 Thread Naheem Zaffar
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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-05-02 Thread Benson Muite



On 05/02/2018 05:52 PM, James Hogarth wrote:

On 2 May 2018 at 12:11, Marek Greško  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/nextcloud/nextcloud.spec?expand=1

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-05-02 Thread James Hogarth
On 2 May 2018 at 12:11, Marek Greško  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-05-02 Thread Marek Greško
Randy, it is the same with nextcloud.

Marek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-05-02 Thread Marek Greško
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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-05-01 Thread Adam Williamson
On Tue, 2018-05-01 at 21:19 +, 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-05-01 Thread mark preston
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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-06 Thread Stephen Gallagher
On Fri, Apr 6, 2018 at 12:07 PM Przemek Klosowski <
przemek.klosow...@nist.gov> wrote:

> On 04/04/2018 02:53 PM, Stephen Gallagher wrote:
> > On F28
> > `dnf install php:8/server` (Assuming there's a profile called "server"
> > with the packages one would need to use PHP in a server context)
> >
> > On F29, if you have the php:7 module enabled in F28, an upgrade will
> > not switch this on you. If it's a clean install:
> > `dnf install php:7/server`
>
> after that, it'll remember which one you're on so that 'dnf update php'
> will work in either case, right?
>
>
Yes, you'll only get modules from the installed case.


> BTW, I assume it'll error out on 'dnf install php:7/server; dnf install
> php:8/server'?
>

No, this is interpreted as the user intentionally switching to another
module stream and will replace any packages from php:7 with content from
php:8. It will fail appropriately if you have other packages or modules on
the system that cannot run with the php:8 content, of course.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-06 Thread Przemek Klosowski

On 04/04/2018 02:53 PM, Stephen Gallagher wrote:

On F28
`dnf install php:8/server` (Assuming there's a profile called "server" 
with the packages one would need to use PHP in a server context)


On F29, if you have the php:7 module enabled in F28, an upgrade will 
not switch this on you. If it's a clean install:

`dnf install php:7/server`


after that, it'll remember which one you're on so that 'dnf update php' 
will work in either case, right?


BTW, I assume it'll error out on 'dnf install php:7/server; dnf install 
php:8/server'?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-05 Thread Germano Massullo
Il 04/04/2018 22:49, James Hogarth ha scritto:
> On Wed, 4 Apr 2018, 20:26 Adam Williamson,  > wrote:
>
> On Wed, 2018-04-04 at 11:15 +0100, James Hogarth wrote:
> > On 4 April 2018 at 11:01, David Sommerseth  > 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-le...@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-de...@lists.fedoraproject.org/thread/7LRBYZL2NF5EZSNVILIEK64LSJ534O6X/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread Stephen Gallagher
On Wed, Apr 4, 2018 at 4:53 PM James Hogarth 
wrote:

> On Wed, 4 Apr 2018, 19:54 Stephen Gallagher,  wrote:
>
>>
>> On F28
>> `dnf install php:8/server` (Assuming there's a profile called "server"
>> with the packages one would need to use PHP in a server context)
>>
>> On F29, if you have the php:7 module enabled in F28, an upgrade will not
>> switch this on you. If it's a clean install:
>> `dnf install php:7/server`
>>
>> (Note: I don't know if PHP is backwards-compatible between minor
>> versions; If it's not, then it would probably be php:7.2 and php:8.0
>> instead)
>>
> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
> This is intriguing and a big improvement over the previous plans I alluded
> to.
>
> Once we've got the update train going, and F28 is released,  could I
> please pick your brains a bit on this?
>
>
Absolutely, I'm at your disposal. Also feel free to join #fedora-modularity
on Freenode, where I and other folks working on the plumbing hang out.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread James Hogarth
On Wed, 4 Apr 2018, 19:54 Stephen Gallagher,  wrote:

>
>
> On Wed, Apr 4, 2018 at 2:36 PM Przemek Klosowski <
> przemek.klosow...@nist.gov> wrote:
>
>> On 04/04/2018 01:59 PM, Stephen Gallagher wrote:
>> > The short version is that Modules *are* distribution packages. They're
>> > just distribution packages that allow you to pick which major release
>> > stream you want to stay on. We also have a distribution-level defaults
>> > setup that allows you to pick one stream from the module and call that
>> > the "default" for a particular Fedora release. Once that stream is so
>> > marked, it just shows up automatically in DNF identically to the way
>> > that traditional distribution RPMs do today. So let's say that in
>> > Fedora 28 you make PHP into a module with the stream "7.2". We mark
>> > that as the default. People can then `dnf install php` exactly as they
>> > always could; the only thing they might see different would be the
>> > %{release} tag of the RPM.
>> >
>> > Now, let's assume that PHP upstream decided to release 8.0 next month.
>> > Fedora 29 would probably use that as its default module and would
>> > package the same way as the above. *However*, you now also have the
>> > opportunity to mark the module as being available for both F28 and F29
>> > and the Module Build Service would produce it for both. And now users
>> > of Fedora 28 can opt in to 8.0 before F29 is released if they want to.
>> > And the reverse is true as well: when upgrading to Fedora 29, users
>> > can opt to keep their version of PHP on 7.2 to continue supporting
>> > their application.
>> >
>> This is cool---so what command do you use to choose PHP  8.0 in F28? and
>> how do you choose to stay on 7.2 in F29?
>>
>>
> On F28
> `dnf install php:8/server` (Assuming there's a profile called "server"
> with the packages one would need to use PHP in a server context)
>
> On F29, if you have the php:7 module enabled in F28, an upgrade will not
> switch this on you. If it's a clean install:
> `dnf install php:7/server`
>
> (Note: I don't know if PHP is backwards-compatible between minor versions;
> If it's not, then it would probably be php:7.2 and php:8.0 instead)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org


This is intriguing and a big improvement over the previous plans I alluded
to.

Once we've got the update train going, and F28 is released,  could I please
pick your brains a bit on this?

Combined with my ansible playbooks (which a quick look at the fedora-ci
wiki pages I think I might be able to use there) it really could make life
easier and even allow users to change major version at their own
preference.

>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread James Hogarth
On Wed, 4 Apr 2018, 20:26 Adam Williamson, 
wrote:

> On Wed, 2018-04-04 at 11:15 +0100, James Hogarth wrote:
> > On 4 April 2018 at 11:01, David Sommerseth  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-le...@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.


>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread James Hogarth
On Wed, 4 Apr 2018, 18:39 Kevin Fenzi,  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.html
> for more info.
>
> kevin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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 ;)

>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread Adam Williamson
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread Adam Williamson
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread Adam Williamson
On Wed, 2018-04-04 at 11:15 +0100, James Hogarth wrote:
> On 4 April 2018 at 11:01, David Sommerseth  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-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread Stephen Gallagher
On Wed, Apr 4, 2018 at 2:36 PM Przemek Klosowski 
wrote:

> On 04/04/2018 01:59 PM, Stephen Gallagher wrote:
> > The short version is that Modules *are* distribution packages. They're
> > just distribution packages that allow you to pick which major release
> > stream you want to stay on. We also have a distribution-level defaults
> > setup that allows you to pick one stream from the module and call that
> > the "default" for a particular Fedora release. Once that stream is so
> > marked, it just shows up automatically in DNF identically to the way
> > that traditional distribution RPMs do today. So let's say that in
> > Fedora 28 you make PHP into a module with the stream "7.2". We mark
> > that as the default. People can then `dnf install php` exactly as they
> > always could; the only thing they might see different would be the
> > %{release} tag of the RPM.
> >
> > Now, let's assume that PHP upstream decided to release 8.0 next month.
> > Fedora 29 would probably use that as its default module and would
> > package the same way as the above. *However*, you now also have the
> > opportunity to mark the module as being available for both F28 and F29
> > and the Module Build Service would produce it for both. And now users
> > of Fedora 28 can opt in to 8.0 before F29 is released if they want to.
> > And the reverse is true as well: when upgrading to Fedora 29, users
> > can opt to keep their version of PHP on 7.2 to continue supporting
> > their application.
> >
> This is cool---so what command do you use to choose PHP  8.0 in F28? and
> how do you choose to stay on 7.2 in F29?
>
>
On F28
`dnf install php:8/server` (Assuming there's a profile called "server" with
the packages one would need to use PHP in a server context)

On F29, if you have the php:7 module enabled in F28, an upgrade will not
switch this on you. If it's a clean install:
`dnf install php:7/server`

(Note: I don't know if PHP is backwards-compatible between minor versions;
If it's not, then it would probably be php:7.2 and php:8.0 instead)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread Przemek Klosowski

On 04/04/2018 01:59 PM, Stephen Gallagher wrote:
The short version is that Modules *are* distribution packages. They're 
just distribution packages that allow you to pick which major release 
stream you want to stay on. We also have a distribution-level defaults 
setup that allows you to pick one stream from the module and call that 
the "default" for a particular Fedora release. Once that stream is so 
marked, it just shows up automatically in DNF identically to the way 
that traditional distribution RPMs do today. So let's say that in 
Fedora 28 you make PHP into a module with the stream "7.2". We mark 
that as the default. People can then `dnf install php` exactly as they 
always could; the only thing they might see different would be the 
%{release} tag of the RPM.


Now, let's assume that PHP upstream decided to release 8.0 next month. 
Fedora 29 would probably use that as its default module and would 
package the same way as the above. *However*, you now also have the 
opportunity to mark the module as being available for both F28 and F29 
and the Module Build Service would produce it for both. And now users 
of Fedora 28 can opt in to 8.0 before F29 is released if they want to. 
And the reverse is true as well: when upgrading to Fedora 29, users 
can opt to keep their version of PHP on 7.2 to continue supporting 
their application.


This is cool---so what command do you use to choose PHP  8.0 in F28? and 
how do you choose to stay on 7.2 in F29?



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread Stephen Gallagher
On Wed, Apr 4, 2018 at 12:59 PM Reindl Harald 
wrote:

>
>
> Am 04.04.2018 um 17:36 schrieb Stephen Gallagher:
> > Hopefully this will become easier once we get the PHP maintainers to
> > move over to building Fedora Modules. Then we can decouple the PHP
> > updates from the Fedora release and we can tie the NextCloud streams to
> > a known-working PHP stream
>
> thanks god i biuld the PHP stack for a decade on my own - go away with
> the "modules and atomic only attitude" - or at least don't compromise
> parts of Fedora which i still prefer as distribution packages - that
> won't change and before it changes 40 machines are moved to a different
> distribution
>
> OK,  I'm going to try to translate this, because it wasn't altogether
coherent.

I *suspect* you're confusing the version of Modularity that we're shipping
in Fedora 28 Beta with the one we prototyped and abandoned during the
Fedora 26 and 27 cycles.

The short version is that Modules *are* distribution packages. They're just
distribution packages that allow you to pick which major release stream you
want to stay on. We also have a distribution-level defaults setup that
allows you to pick one stream from the module and call that the "default"
for a particular Fedora release. Once that stream is so marked, it just
shows up automatically in DNF identically to the way that traditional
distribution RPMs do today. So let's say that in Fedora 28 you make PHP
into a module with the stream "7.2". We mark that as the default. People
can then `dnf install php` exactly as they always could; the only thing
they might see different would be the %{release} tag of the RPM.

Now, let's assume that PHP upstream decided to release 8.0 next month.
Fedora 29 would probably use that as its default module and would package
the same way as the above. *However*, you now also have the opportunity to
mark the module as being available for both F28 and F29 and the Module
Build Service would produce it for both. And now users of Fedora 28 can opt
in to 8.0 before F29 is released if they want to. And the reverse is true
as well: when upgrading to Fedora 29, users can opt to keep their version
of PHP on 7.2 to continue supporting their application.

So, to recap, packaging as modules means you can avoid people complaining
about
1) "The version in Fedora is too old! I want the latest one!"
2) "I upgraded to the new Fedora release and my application stopped
working!"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread Stephen Gallagher
On Wed, Apr 4, 2018 at 12:05 PM James Hogarth 
wrote:

> On Wed, 4 Apr 2018, 16:37 Stephen Gallagher,  wrote:
>
>>
>>
>> On Wed, Apr 4, 2018 at 11:34 AM James Hogarth 
>> wrote:
>>
>>>
>>>
>>> On Wed, 4 Apr 2018, 15:59 Reindl Harald,  wrote:
>>>


 Am 04.04.2018 um 16:51 schrieb James Hogarth:
 > 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"

 because "$preserveMtime" is missing in one declaration and you must have
 missed 1.5 years of PHP 7.0/7.1/7.2

 "Declaration of ** must be compatible with **" is pretty clear and
 nothing new, that was even a warning with PHP5 on a proper setup with
 error_reporting = E_ALL for many years

>>>
>>> Yes the error is clear... the fixes to get this working are suddenly
>>> nontrivial when I need to test a bunch of stuff in spare minutes between
>>> $realjob tasks.
>>>
>>> Keep in mind this is not my code... this is owncloud code that I'll need
>>> to write maintainer patches for to ensure it works on F27 and F28 ... at
>>> times this means backporting changes ... especially where major php version
>>> changes are concerned.
>>>
>>> This isn't usual  - indeed at a Fedora release that has a major PHP
>>> update much of my time will be spent on tackling issues like these.
>>>
>>> I expect to spend 3-4 hours in bed tonight into the wee hours of the
>>> morning getting the basics in place so the current version can be safely
>>> installed on F28 and still run on F27 for both owncloud and nextcloud ...
>>> and then we can look to the major updates.
>>>
>>>
>> Hopefully this will become easier once we get the PHP maintainers to move
>> over to building Fedora Modules. Then we can decouple the PHP updates from
>> the Fedora release and we can tie the NextCloud streams to a known-working
>> PHP stream.
>>
> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
> Haha poor Remi will get to do even more php testing  ;)
>
> Though to be fair he already does a lot of that with his own repos and
> multiple php versions there.
>
>
Well, the idea is that it will be possible to build the same stack for
multiple Fedora releases at the same time and then just pick which stream
is the "default" for the release, which will just simply appear to
end-users much the same way that it does today as a standard package in an
RPM repository.



> The modular server release was frankly a disaster... and we all know it.
>

I suspect you're thinking of the original design which was scrapped. I'm
referring to the current approach that we just shipped in Fedora 28 that is
purely add-on to the traditional deployment. Please don't confuse the two.



>
> But lessons were learned which is of course important.
>
>
Not just learned, but fixes implemented!


> I'm honestly not sure how much that will really simplify maintenance of
> this... or what the path from standard fedora rpm to this would be for
> someone.
>
>
As far as the path from standard RPM to modules, as long as we are mindful
of which module stream is default (or explicitly selected), then from an
end-user perspective it'll just look like a standard DNF update.

Frankly I fear it'll actually increase my test matrix potentially (standard
> plus modular) ...
>
>
Well, given what I've read in this thread, it seems to me that we can
actually reduce your matrix significantly.
1) You wouldn't need "standard" as long as you identified a module stream
to be the default for the release. That stream will just show up to DNF as
if it was "standard".
2) If both this and PHP use modules, NC can declare that it requires PHP
e.g. 8.5 for runtime and it will always stick to that, so you can avoid
having to move to a newer PHP base until upstream supports it.

With this in mind, I think it would be a lot easier to maintain it. Then
the upgrade instructions would basically become:
```
dnf module enable owncloud:N+1

```
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread Kevin Fenzi
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.html
for more info.

kevin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread James Hogarth
On Wed, 4 Apr 2018, 16:37 Stephen Gallagher,  wrote:

>
>
> On Wed, Apr 4, 2018 at 11:34 AM James Hogarth 
> wrote:
>
>>
>>
>> On Wed, 4 Apr 2018, 15:59 Reindl Harald,  wrote:
>>
>>>
>>>
>>> Am 04.04.2018 um 16:51 schrieb James Hogarth:
>>> > 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"
>>>
>>> because "$preserveMtime" is missing in one declaration and you must have
>>> missed 1.5 years of PHP 7.0/7.1/7.2
>>>
>>> "Declaration of ** must be compatible with **" is pretty clear and
>>> nothing new, that was even a warning with PHP5 on a proper setup with
>>> error_reporting = E_ALL for many years
>>>
>>
>> Yes the error is clear... the fixes to get this working are suddenly
>> nontrivial when I need to test a bunch of stuff in spare minutes between
>> $realjob tasks.
>>
>> Keep in mind this is not my code... this is owncloud code that I'll need
>> to write maintainer patches for to ensure it works on F27 and F28 ... at
>> times this means backporting changes ... especially where major php version
>> changes are concerned.
>>
>> This isn't usual  - indeed at a Fedora release that has a major PHP
>> update much of my time will be spent on tackling issues like these.
>>
>> I expect to spend 3-4 hours in bed tonight into the wee hours of the
>> morning getting the basics in place so the current version can be safely
>> installed on F28 and still run on F27 for both owncloud and nextcloud ...
>> and then we can look to the major updates.
>>
>>
> Hopefully this will become easier once we get the PHP maintainers to move
> over to building Fedora Modules. Then we can decouple the PHP updates from
> the Fedora release and we can tie the NextCloud streams to a known-working
> PHP stream.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Haha poor Remi will get to do even more php testing  ;)

Though to be fair he already does a lot of that with his own repos and
multiple php versions there.

The modular server release was frankly a disaster... and we all know it.

But lessons were learned which is of course important.

I'm honestly not sure how much that will really simplify maintenance of
this... or what the path from standard fedora rpm to this would be for
someone.

Frankly I fear it'll actually increase my test matrix potentially (standard
plus modular) ...

>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread James Hogarth
On Wed, 4 Apr 2018, 16:51 William Moreno, 
wrote:

>
>
> 2018-04-04 9:43 GMT-06:00 Randy Barlow :
>
>> 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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.



>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread Mattia Verga


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?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread William Moreno
2018-04-04 9:43 GMT-06:00 Randy Barlow :

> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Local test VMs (was: Status of OwnCloud/NextCloud)

2018-04-04 Thread James Hogarth
On Wed, 4 Apr 2018, 16:11 Tim Landscheidt,  wrote:

> James Hogarth  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-le...@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


>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread Randy Barlow
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread William Moreno
2018-04-04 8:51 GMT-06:00 James Hogarth :

> On 4 April 2018 at 14:48, William Moreno
>  wrote:
> >
> >
> > 2018-04-03 13:11 GMT-06:00 Stephen Gallagher :
> >>
> >>
> >>
> >> On Tue, Apr 3, 2018 at 3:01 PM 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?
> >>
> >>
> >>
> >> 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) =
> `
> >> 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread Stephen Gallagher
On Wed, Apr 4, 2018 at 11:34 AM James Hogarth 
wrote:

>
>
> On Wed, 4 Apr 2018, 15:59 Reindl Harald,  wrote:
>
>>
>>
>> Am 04.04.2018 um 16:51 schrieb James Hogarth:
>> > 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"
>>
>> because "$preserveMtime" is missing in one declaration and you must have
>> missed 1.5 years of PHP 7.0/7.1/7.2
>>
>> "Declaration of ** must be compatible with **" is pretty clear and
>> nothing new, that was even a warning with PHP5 on a proper setup with
>> error_reporting = E_ALL for many years
>>
>
> Yes the error is clear... the fixes to get this working are suddenly
> nontrivial when I need to test a bunch of stuff in spare minutes between
> $realjob tasks.
>
> Keep in mind this is not my code... this is owncloud code that I'll need
> to write maintainer patches for to ensure it works on F27 and F28 ... at
> times this means backporting changes ... especially where major php version
> changes are concerned.
>
> This isn't usual  - indeed at a Fedora release that has a major PHP update
> much of my time will be spent on tackling issues like these.
>
> I expect to spend 3-4 hours in bed tonight into the wee hours of the
> morning getting the basics in place so the current version can be safely
> installed on F28 and still run on F27 for both owncloud and nextcloud ...
> and then we can look to the major updates.
>
>
Hopefully this will become easier once we get the PHP maintainers to move
over to building Fedora Modules. Then we can decouple the PHP updates from
the Fedora release and we can tie the NextCloud streams to a known-working
PHP stream.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread James Hogarth
On Wed, 4 Apr 2018, 16:27 Randy Barlow, 
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-le...@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.


>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread James Hogarth
On Wed, 4 Apr 2018, 15:59 Reindl Harald,  wrote:

>
>
> Am 04.04.2018 um 16:51 schrieb James Hogarth:
> > 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"
>
> because "$preserveMtime" is missing in one declaration and you must have
> missed 1.5 years of PHP 7.0/7.1/7.2
>
> "Declaration of ** must be compatible with **" is pretty clear and
> nothing new, that was even a warning with PHP5 on a proper setup with
> error_reporting = E_ALL for many years
>

Yes the error is clear... the fixes to get this working are suddenly
nontrivial when I need to test a bunch of stuff in spare minutes between
$realjob tasks.

Keep in mind this is not my code... this is owncloud code that I'll need to
write maintainer patches for to ensure it works on F27 and F28 ... at times
this means backporting changes ... especially where major php version
changes are concerned.

This isn't usual  - indeed at a Fedora release that has a major PHP update
much of my time will be spent on tackling issues like these.

I expect to spend 3-4 hours in bed tonight into the wee hours of the
morning getting the basics in place so the current version can be safely
installed on F28 and still run on F27 for both owncloud and nextcloud ...
and then we can look to the major updates.

>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread Randy Barlow
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-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread Randy Barlow
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 ☺
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Local test VMs (was: Status of OwnCloud/NextCloud)

2018-04-04 Thread Tim Landscheidt
James Hogarth  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-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread Randy Barlow
On 04/04/2018 09:48 AM, William Moreno wrote:
> +1 should be a nice changes for the F29 release. 

Since OwnCloud is completely broken on F28 right now (not sure about
NextCloud, but it might be as well), it could be nice to do for F28 as well.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread Randy Barlow
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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread James Hogarth
On 4 April 2018 at 14:48, William Moreno
 wrote:
>
>
> 2018-04-03 13:11 GMT-06:00 Stephen Gallagher :
>>
>>
>>
>> On Tue, Apr 3, 2018 at 3:01 PM 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?
>>
>>
>>
>> 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) = `
>> 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread William Moreno
2018-04-03 13:11 GMT-06:00 Stephen Gallagher :

>
>
> On Tue, Apr 3, 2018 at 3:01 PM 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?
>>
>
>
> 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) =
> ` 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread James Hogarth
On 4 April 2018 at 11:01, David Sommerseth  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread James Hogarth
On 4 April 2018 at 08:38, Benson Muite  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-le...@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 ;)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 

Re: Status of OwnCloud/NextCloud

2018-04-04 Thread David Sommerseth
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



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread Benson Muite




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-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-04 Thread Jonathan Dieter
On Tue, 2018-04-03 at 19:00 +, 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-03 Thread Remi Collet
Le 03/04/2018 à 19:44, Dennis Gilmore a écrit :
> El mar, 03-04-2018 a las 17:07 +, Stephen Gallagher escribió:
>> On Tue, Apr 3, 2018 at 12:39 PM Christian 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-03 Thread Chris Murphy
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-03 Thread Christian Glombek
Totally agreed. I'd expect having streams for each major would
somewhat mitigate this.

Adam Williamson  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-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-03 Thread Adam Williamson
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-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-03 Thread Christian Glombek
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  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-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-03 Thread Randy Barlow
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-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-03 Thread Stephen Gallagher
On Tue, Apr 3, 2018 at 3:01 PM 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?
>


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) =
` 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?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-03 Thread Ben Rosser
On Tue, Apr 3, 2018 at 3:00 PM, 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?

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-03 Thread Christian Glombek
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?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-03 Thread Christian Glombek
Yup, that, essentially.

Some deps that are needed for these versions are already outdated and have 
newer, incompatible versions in the Fedora rpm repos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-03 Thread Dennis Gilmore
El mar, 03-04-2018 a las 17:07 +, Stephen Gallagher escribió:
> On Tue, Apr 3, 2018 at 12:39 PM Christian 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

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-03 Thread Stephen Gallagher
On Tue, Apr 3, 2018 at 12:39 PM Christian Glombek 
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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-03 Thread Christian Glombek
For reference:

https://bugzilla.redhat.com/show_bug.cgi?id=1433919

https://src.fedoraproject.org/rpms/nextcloud/pull-request/3
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-03 Thread Christian Glombek
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  schrieb am Di., 3. Apr. 2018 um
15:36 Uhr:

> On 04/03/2018 09:19 AM, David Sommerseth wrote:
> > Here's some traces ...
> > 
>
> 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-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-03 Thread Randy Barlow
On 04/03/2018 09:19 AM, David Sommerseth wrote:
> Here's some traces ...
> 

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-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-03 Thread David Sommerseth
On 03/04/18 15:13, Peter Robinson wrote:
> On Tue, Apr 3, 2018 at 1:51 PM, Randy Barlow
>  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 ...


Not sure what happened after this.


-- 
kind regards,

David Sommerseth
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Status of OwnCloud/NextCloud

2018-04-03 Thread Peter Robinson
On Tue, Apr 3, 2018 at 1:51 PM, Randy Barlow
 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-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Status of OwnCloud/NextCloud

2018-04-03 Thread Randy Barlow
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?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org