[opensuse-factory] Tumbleweed - Review of the week 2019/51
Dear Tumbleweed users and hackers, The year 2019 is slowly coming to the end, yet Tumbleweed keeps on rolling (so far). During that week we could publish three snapshots (1213, 1214 and 1216). The changes contained therein were: * KDE Applications 19.12.0 * PHP 7.4 One complete snapshot was built (but not released) using kernel 5.4. Unfortunately, we had to revert this update again, as kexec functionality was non-functional with our signed kernel. The issue is being analyzed and fixes are being looked for. Unfortunately, with the holiday season, I can’t predict when this will happen. Other than that, we still have a few things piling up in stagings, like: * Python 3.8 * Rust 1.39 * systemd 244 * Qt 5.14 * Kubernetes 1.17 Unfortunately, there is also an openQA/Networking issue present at the moment. Our openQA workers are unable to connect to multiple sites (all *.opensuse.org) and thus fail to test any of the snapshots/staging areas. We are busy trying to find resources that can fix this up, but this proves not so easy over this period. I hope we can soon resume testing activity with working network setup and restart rolling Tumbleweed Cheers, Dominique
On 12/23/19 10:18 AM, Dominique Leuenberger / DimStar wrote:
The changes contained therein were: [..] * PHP 7.4
Everybody running a nextcloud server on Tumbleweed should be aware that it currently does *not* work with PHP 7.4. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Citeren Michael Ströder <michael@stroeder.com>:
On 12/23/19 10:18 AM, Dominique Leuenberger / DimStar wrote:
The changes contained therein were: [..] * PHP 7.4
Everybody running a nextcloud server on Tumbleweed should be aware that it currently does *not* work with PHP 7.4.
Why this warning? That should be pretty obvious: Problem: nothing provides mod_php_any < 7.4.0 needed by nextcloud-17.0.1-1.1. noarch Solution 1: do not install nextcloud-17.0.1-1.1.noarch Solution 2: break nextcloud-17.0.1-1.1.noarch by ignoring some of its depend encies So unless nextcloud is installed from a third party source, this is handled by the requirements for the nextcloud package. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/23/19 12:41 PM, Arjen de Korte wrote:
Citeren Michael Ströder <michael@stroeder.com>:
On 12/23/19 10:18 AM, Dominique Leuenberger / DimStar wrote:
The changes contained therein were: [..] * PHP 7.4
Everybody running a nextcloud server on Tumbleweed should be aware that it currently does *not* work with PHP 7.4.
Why this warning? That should be pretty obvious:
Problem: nothing provides mod_php_any < 7.4.0 needed by nextcloud-17.0.1-1.1.
Two reasons: 1. It's an nextcloud upstream constraint and not just an obsolete package version dependency. 2. It raises the question why Tumbleweed ships an PHP update which prevents the installation of applications also shipped with Tumbleweed. IMHO this contradicts the aim to ship a quality-tested rolling release. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2019-12-23 at 14:43 +0100, Michael Ströder wrote:
On 12/23/19 12:41 PM, Arjen de Korte wrote:
Citeren Michael Ströder <michael@stroeder.com>:
On 12/23/19 10:18 AM, Dominique Leuenberger / DimStar wrote:
The changes contained therein were: [..] * PHP 7.4
Everybody running a nextcloud server on Tumbleweed should be aware that it currently does *not* work with PHP 7.4.
Why this warning? That should be pretty obvious:
Problem: nothing provides mod_php_any < 7.4.0 needed by nextcloud-17.0.1-1.1.
2. It raises the question why Tumbleweed ships an PHP update which prevents the installation of applications also shipped with Tumbleweed. IMHO this contradicts the aim to ship a quality-tested rolling release.
Simple: PHP is tested (in openQA); Nextcloud is not. So there was no indication that this would break. At any given time, there are dozens of uninstallable packages in Tumbleweed, see https://build.opensuse.org/package/view_file/openSUSE:Factory:Staging/dashbo... I'll just drop nextcloud from openSUSE:Factory - so we don't ship the broken stuff and also don't have to ship PHP 7.3 with open CVEs IMHO, NextCloud is given 'too much power in blocking server admins to update to latest / secure versions of PHP'; They simply ignore all of the beta phase for php. Even though tickets are filed long ago. IIRC, php7.4 tickets were filed with nextcloud in July - The plan is to support PHP 7.4 only with NC18 (supposedly comming out January, so at least the gap is not huge this time) Cheers, Dominique
Don't think nextcloud is the problem. I think PHP 7.4 is the problem. PHP 7.4 comes to early to Tumbleweed. And bugentries not ignored, but i can do nothing. Ist's upstream. And i can understand upstream. Why not offer both PHP Versions? Newest and one version before. Think others applications does also not support 7.4 Regards Eric Am 23. Dezember 2019 15:01:06 MEZ schrieb Dominique Leuenberger / DimStar <dimstar@opensuse.org>:
On Mon, 2019-12-23 at 14:43 +0100, Michael Ströder wrote:
On 12/23/19 12:41 PM, Arjen de Korte wrote:
Citeren Michael Ströder <michael@stroeder.com>:
On 12/23/19 10:18 AM, Dominique Leuenberger / DimStar wrote:
The changes contained therein were: [..] * PHP 7.4
Everybody running a nextcloud server on Tumbleweed should be aware that it currently does *not* work with PHP 7.4.
Why this warning? That should be pretty obvious:
Problem: nothing provides mod_php_any < 7.4.0 needed by nextcloud-17.0.1-1.1.
2. It raises the question why Tumbleweed ships an PHP update which prevents the installation of applications also shipped with Tumbleweed. IMHO this contradicts the aim to ship a quality-tested rolling release.
Simple:
PHP is tested (in openQA); Nextcloud is not.
So there was no indication that this would break. At any given time, there are dozens of uninstallable packages in Tumbleweed, see https://build.opensuse.org/package/view_file/openSUSE:Factory:Staging/dashbo...
I'll just drop nextcloud from openSUSE:Factory - so we don't ship the broken stuff and also don't have to ship PHP 7.3 with open CVEs
IMHO, NextCloud is given 'too much power in blocking server admins to update to latest / secure versions of PHP'; They simply ignore all of the beta phase for php. Even though tickets are filed long ago. IIRC, php7.4 tickets were filed with nextcloud in July - The plan is to support PHP 7.4 only with NC18 (supposedly comming out January, so at least the gap is not huge this time)
Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 23.12.19 um 18:21 schrieb Eric Schirra:
Don't think nextcloud is the problem. I think PHP 7.4 is the problem. PHP 7.4 comes to early to Tumbleweed. And bugentries not ignored, but i can do nothing. Ist's upstream. And i can understand upstream.
Why not offer both PHP Versions? Newest and one version before.
Feel free to package php in a way to be installable in parallel - we did the same for go and ruby. Greetings, Stephan -- Lighten up, just enjoy life, smile more, laugh more, and don't get so worked up about things. Kenneth Branagh -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/23/19 3:01 PM, Dominique Leuenberger / DimStar wrote:
On Mon, 2019-12-23 at 14:43 +0100, Michael Ströder wrote:
2. It raises the question why Tumbleweed ships an PHP update which prevents the installation of applications also shipped with Tumbleweed. IMHO this contradicts the aim to ship a quality-tested rolling release.
Simple:
PHP is tested (in openQA); Nextcloud is not.
So there was no indication that this would break. At any given time, there are dozens of uninstallable packages in Tumbleweed, see https://build.opensuse.org/package/view_file/openSUSE:Factory:Staging/dashbo...
I'll just drop nextcloud from openSUSE:Factory - so we don't ship the broken stuff and also don't have to ship PHP 7.3 with open CVEs
Fair enough. But why do you feel comfortable to drop a widely used application like nextcloud while the list above contains so many other broken packages? Is it just personal preference? Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
And in some days you can add it again. This ist not the solution for me. The problem is describe in others Mail. PHP 7.4 is too quickly in TW. PHP 7.4 is out since 28.11! Am 23. Dezember 2019 18:53:21 MEZ schrieb "Michael Ströder" <michael@stroeder.com>:
On 12/23/19 3:01 PM, Dominique Leuenberger / DimStar wrote:
On Mon, 2019-12-23 at 14:43 +0100, Michael Ströder wrote:
2. It raises the question why Tumbleweed ships an PHP update which prevents the installation of applications also shipped with Tumbleweed. IMHO this contradicts the aim to ship a quality-tested rolling release.
Simple:
PHP is tested (in openQA); Nextcloud is not.
So there was no indication that this would break. At any given time, there are dozens of uninstallable packages in Tumbleweed, see
https://build.opensuse.org/package/view_file/openSUSE:Factory:Staging/dashbo...
I'll just drop nextcloud from openSUSE:Factory - so we don't ship the broken stuff and also don't have to ship PHP 7.3 with open CVEs
Fair enough.
But why do you feel comfortable to drop a widely used application like nextcloud while the list above contains so many other broken packages? Is it just personal preference?
Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Montag, 23. Dezember 2019, 19:02:25 CET schrieb Eric Schirra:
And in some days you can add it again. This ist not the solution for me. The problem is describe in others Mail. PHP 7.4 is too quickly in TW. PHP 7.4 is out since 28.11!
Thats what a rolling release does - it rolls quickly. So if you have a productive installation of nextcloud, Leap would probably be the better option. And having an openQA test for nextcloud would even be better. Until then...build PHP 7.3 Best Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
You must say this not to me. Read my mails. Thats one reason why i not use Tumbleweed. And i'm anyway the opinion, that's PHP 7.4 is to quickly in tumbleweed. Not for me, but for others. Am 23. Dezember 2019 19:36:32 MEZ schrieb Axel Braun <axel.braun@gmx.de>:
Am Montag, 23. Dezember 2019, 19:02:25 CET schrieb Eric Schirra:
And in some days you can add it again. This ist not the solution for me. The problem is describe in others Mail. PHP 7.4 is too quickly in TW. PHP 7.4 is out since 28.11!
Thats what a rolling release does - it rolls quickly. So if you have a productive installation of nextcloud, Leap would probably be the better option. And having an openQA test for nextcloud would even be better. Until then...build PHP 7.3
Best Axel
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Citeren Axel Braun <axel.braun@gmx.de>:
Am Montag, 23. Dezember 2019, 19:02:25 CET schrieb Eric Schirra:
And in some days you can add it again. This ist not the solution for me. The problem is describe in others Mail. PHP 7.4 is too quickly in TW. PHP 7.4 is out since 28.11!
Thats what a rolling release does - it rolls quickly. So if you have a productive installation of nextcloud, Leap would probably be the better option. And having an openQA test for nextcloud would even be better.
I think the only thing that an openQA test for nextcloud would bring, is a reason not to include it in Tumbleweed. This is not the first time a PHP upgrade breaks nextcloud (and it probably won't be the last time either). It looks like the nextcloud developers are either not able or willing to keep up with the pace of PHP development. The incompatibilities are known for months already, yet a fix will not be available until almost two months after the release of PHP 7.4.
Until then...build PHP 7.3
Best Axel
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I think that has nothing to do with "no willing". The time for testing is simple too short. 7.4 is out since 28.11. Too test all, the time is too short. And in my opinion, 7.4 in tumbleweed is to quickly. I'm not from upstream. It's only my opinion. Regards Eric Am 23. Dezember 2019 20:46:11 MEZ schrieb Arjen de Korte <suse+factory@de-korte.org>:
Citeren Axel Braun <axel.braun@gmx.de>:
Am Montag, 23. Dezember 2019, 19:02:25 CET schrieb Eric Schirra:
And in some days you can add it again. This ist not the solution for me. The problem is describe in others Mail. PHP 7.4 is too quickly in TW. PHP 7.4 is out since 28.11!
Thats what a rolling release does - it rolls quickly. So if you have a productive installation of nextcloud, Leap would probably be the better option. And having an openQA test for nextcloud would even be better.
I think the only thing that an openQA test for nextcloud would bring, is a reason not to include it in Tumbleweed.
This is not the first time a PHP upgrade breaks nextcloud (and it probably won't be the last time either). It looks like the nextcloud developers are either not able or willing to keep up with the pace of PHP development.
The incompatibilities are known for months already, yet a fix will not
be available until almost two months after the release of PHP 7.4.
Until then...build PHP 7.3
Best Axel
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Citeren Eric Schirra <ecsos@opensuse.org>:
I think that has nothing to do with "no willing".
It absolutely is. It is a decision made upstream to introduce PHP 7.4 support in NC18, which will not be available until the second half of January. Not synchronizing NC releases with PHP releases is a major roadblock to keep up with rolling releases like Tumbleweed (and Arch for instance).
The time for testing is simple too short. 7.4 is out since 28.11.
The changes required to support PHP 7.4 are already known for months. The first alpha release for 7.4.0 was in June, if memory serves. That's what all the alpha/beta/release candidates are for. To test compatibility with the upcoming final releases.
Too test all, the time is too short.
I beg to differ. See above. If you wait until the final release, you'll always be too late. And I can predict that nextcloud will not be compatible to PHP 8 when that is released either.
And in my opinion, 7.4 in tumbleweed is to quickly.
It was delayed three weeks actually.
I'm not from upstream. It's only my opinion.
Regards Eric
Am 23. Dezember 2019 20:46:11 MEZ schrieb Arjen de Korte <suse+factory@de-korte.org>:
Citeren Axel Braun <axel.braun@gmx.de>:
Am Montag, 23. Dezember 2019, 19:02:25 CET schrieb Eric Schirra:
And in some days you can add it again. This ist not the solution for me. The problem is describe in others Mail. PHP 7.4 is too quickly in TW. PHP 7.4 is out since 28.11!
Thats what a rolling release does - it rolls quickly. So if you have a productive installation of nextcloud, Leap would probably be the better option. And having an openQA test for nextcloud would even be better.
I think the only thing that an openQA test for nextcloud would bring, is a reason not to include it in Tumbleweed.
This is not the first time a PHP upgrade breaks nextcloud (and it probably won't be the last time either). It looks like the nextcloud developers are either not able or willing to keep up with the pace of PHP development.
The incompatibilities are known for months already, yet a fix will not
be available until almost two months after the release of PHP 7.4.
Until then...build PHP 7.3
Best Axel
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
When i was Developer i would begin to test when PHP Version ist releases. Not before. This ist in my opinion one reason why upstream use more and more flat, SNAP, docker and so on. Am 23. Dezember 2019 22:10:07 MEZ schrieb Arjen de Korte <suse+factory@de-korte.org>:
Citeren Eric Schirra <ecsos@opensuse.org>:
I think that has nothing to do with "no willing".
It absolutely is. It is a decision made upstream to introduce PHP 7.4 support in NC18, which will not be available until the second half of January. Not synchronizing NC releases with PHP releases is a major roadblock to keep up with rolling releases like Tumbleweed (and Arch for instance).
The time for testing is simple too short. 7.4 is out since 28.11.
The changes required to support PHP 7.4 are already known for months. The first alpha release for 7.4.0 was in June, if memory serves. That's what all the alpha/beta/release candidates are for. To test compatibility with the upcoming final releases.
Too test all, the time is too short.
I beg to differ. See above. If you wait until the final release, you'll always be too late. And I can predict that nextcloud will not be compatible to PHP 8 when that is released either.
And in my opinion, 7.4 in tumbleweed is to quickly.
It was delayed three weeks actually.
I'm not from upstream. It's only my opinion.
Regards Eric
Am 23. Dezember 2019 20:46:11 MEZ schrieb Arjen de Korte <suse+factory@de-korte.org>:
Citeren Axel Braun <axel.braun@gmx.de>:
Am Montag, 23. Dezember 2019, 19:02:25 CET schrieb Eric Schirra:
And in some days you can add it again. This ist not the solution for me. The problem is describe in others Mail. PHP 7.4 is too quickly in TW. PHP 7.4 is out since 28.11!
Thats what a rolling release does - it rolls quickly. So if you have a productive installation of nextcloud, Leap would probably be the better option. And having an openQA test for nextcloud would even be better.
I think the only thing that an openQA test for nextcloud would bring, is a reason not to include it in Tumbleweed.
This is not the first time a PHP upgrade breaks nextcloud (and it probably won't be the last time either). It looks like the nextcloud developers are either not able or willing to keep up with the pace of PHP development.
The incompatibilities are known for months already, yet a fix will not
be available until almost two months after the release of PHP 7.4.
Until then...build PHP 7.3
Best Axel
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Montag, 23. Dezember 2019, 23:53:42 CET schrieb Eric Schirra:
When i was Developer i would begin to test when PHP Version ist releases. Not before. This ist in my opinion one reason why upstream use more and more flat, SNAP, docker and so on.
And each and every project security audits each and every package/library they ship! What a wonderful NIGHTMARE the world can be. Sure, lazy and hazy people like this, and the bad guys, of course. Cheers and merry Christmas, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 24. Dezember 2019 20:22:08 MEZ schrieb Hans-Peter Jansen <hpj@urpla.net>:
Am Montag, 23. Dezember 2019, 23:53:42 CET schrieb Eric Schirra:
When i was Developer i would begin to test when PHP Version ist releases. Not before. This ist in my opinion one reason why upstream use more and more flat, SNAP, docker and so on.
And each and every project security audits each and every package/library they ship!
What a wonderful NIGHTMARE the world can be.
Sure, lazy and hazy people like this, and the bad guys, of course.
Yes unfortunately. And in my opinion, the distributions are not blameless. Merry Christmas. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Dec 23, 2019 at 5:53 PM Eric Schirra <ecsos@opensuse.org> wrote:
When i was Developer i would begin to test when PHP Version ist releases. Not before. This ist in my opinion one reason why upstream use more and more flat, SNAP, docker and so on.
In general, it's not very smart to not begin testing as early as possible with the next version of the language that your software is built on... Unless you *know* you're in for a bad time, testing during the betas allows you to easily keep up with changes as they come and provide valuable feedback to make the runtime even better. Historically, this has been the duty of distributions. However, outside of Python and GCC (C/C++) in Fedora, I know of no distribution-level testing of a wide range of libraries and applications to validate a language stack. In theory, openSUSE could do this, but it takes a lot of work to set up properly and have the fortitude and energy to work with upstreams to get things fixed quickly. But if the openSUSE PHP stack maintainers hold an attitude like yours, then clearly openSUSE will never be that place for PHP. -- 真実はいつも一つ!/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Neal Gompa schrieb:
On Mon, Dec 23, 2019 at 5:53 PM Eric Schirra <ecsos@opensuse.org> wrote:
When i was Developer i would begin to test when PHP Version ist releases. Not before. This ist in my opinion one reason why upstream use more and more flat, SNAP, docker and so on.
In general, it's not very smart to not begin testing as early as possible with the next version of the language that your software is built on...
So are you saying that using Tumbleweed (which is defined as a distro that has all the new versions as soon as possible) is a bad idea "in general"? KaiRo -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26. Dezember 2019 16:29:19 MEZ schrieb Robert Kaiser <kairo@kairo.at>:
Neal Gompa schrieb:
On Mon, Dec 23, 2019 at 5:53 PM Eric Schirra <ecsos@opensuse.org> wrote:
When i was Developer i would begin to test when PHP Version ist
releases. Not before.
This ist in my opinion one reason why upstream use more and more flat, SNAP, docker and so on.
In general, it's not very smart to not begin testing as early as possible with the next version of the language that your software is built on...
So are you saying that using Tumbleweed (which is defined as a distro that has all the new versions as soon as possible) is a bad idea "in general"?
Not in General. Applications should be rolling. But in my opinion frameworks should not absolute updated before there are necessary for any application. Regards Eric -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Eric Schirra schrieb:
Am 26. Dezember 2019 16:29:19 MEZ schrieb Robert Kaiser <kairo@kairo.at>:
Neal Gompa schrieb:
On Mon, Dec 23, 2019 at 5:53 PM Eric Schirra <ecsos@opensuse.org> wrote:
When i was Developer i would begin to test when PHP Version ist
releases. Not before.
This ist in my opinion one reason why upstream use more and more flat, SNAP, docker and so on.
In general, it's not very smart to not begin testing as early as possible with the next version of the language that your software is built on...
So are you saying that using Tumbleweed (which is defined as a distro that has all the new versions as soon as possible) is a bad idea "in general"?
Not in General. Applications should be rolling. But in my opinion frameworks should not absolute updated before there are necessary for any application.
FWIW, one of the reasons for me to use Tubleweed on my personal machines (which I use for development as well) is to see potential breakage that a newer PHP, MariaDB, kernel, etc. can cause with my code, long before I will stumble over that on my production machines. In the end, what should be in TW based on how TW is used by people may just not be as "in general" as you may see it... ;-) Cheers, KaiRo -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26. Dezember 2019 18:37:21 MEZ schrieb Robert Kaiser <kairo@kairo.at>:
So are you saying that using Tumbleweed (which is defined as a distro that has all the new versions as soon as possible) is a bad idea "in general"?
Not in General. Applications should be rolling. But in my opinion frameworks should not absolute updated before there are necessary for any application.
FWIW, one of the reasons for me to use Tubleweed on my personal machines (which I use for development as well) is to see potential breakage that
a newer PHP, MariaDB, kernel, etc. can cause with my code, long before I will stumble over that on my production machines.
In the end, what should be in TW based on how TW is used by people may just not be as "in general" as you may see it... ;-)
Okay. For your requirements it's right that all packages exists in newest version. I personal use not tumbleweed. But i can understand upstream, that they not always use the newest version or have time to test and migrate quickly. I use Leap and build some applications which i want in newest version for myself in obs. But perfectly where, when it would exists a mix of tumbleweed and Leap. Ground with stable and perhaps older packages versions and with all applications in new version (desktop-apps and Server Apps). This would be perfect for me. Regards Eric -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Dec 26, 2019 at 21:56, Eric Schirra <ecsos@opensuse.org> wrote:
Okay. For your requirements it's right that all packages exists in newest version. I personal use not tumbleweed. But i can understand upstream, that they not always use the newest version or have time to test and migrate quickly. I use Leap and build some applications which i want in newest version for myself in obs. But perfectly where, when it would exists a mix of tumbleweed and Leap. Ground with stable and perhaps older packages versions and with all applications in new version (desktop-apps and Server Apps). This would be perfect for me.
I might recommend to you Flatpak and podman in that case. Flathub [1] provides the newest versions of the desktop applications you might need in Flatpak, and OBS [2] and other registries build containers which you can then use with podman. As a bonus, Flatpak uses bubblewrap and portals, so the applications have less access to your data and devices than standard RPM packages, like the standard permissions system on Android and iOS. podman outdoes docker, while using the same container format, so you aren't losing on the switch, while gaining a little bit better performance and flexibility. And the most important of all, they don't mess with anything else in your installation, so you don't have to worry about version mismatches and unsupported repositories. Also takes away the blame for the problems away from us ;) That's the only reasonable way to get Leap with the new packages in a way supported by somebody for free though. As far as I know there are no other plans for up-to-date packages in Leap, even though it has been suggested for quite a while. [1] https://flathub.org/ [2] https://registry.opensuse.org/ LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26. Dezember 2019 22:22:41 MEZ schrieb Stasiek Michalski <hellcp@opensuse.org>:
On Thu, Dec 26, 2019 at 21:56, Eric Schirra <ecsos@opensuse.org> wrote:
Okay. For your requirements it's right that all packages exists in newest version. I personal use not tumbleweed. But i can understand upstream, that they not always use the newest version or have time to test and migrate quickly. I use Leap and build some applications which i want in newest version
for myself in obs. But perfectly where, when it would exists a mix of tumbleweed and Leap. Ground with stable and perhaps older packages versions and with all applications in new version (desktop-apps and Server Apps). This would be perfect for me.
I might recommend to you Flatpak and podman in that case. Flathub [1] provides the newest versions of the desktop applications you might need in Flatpak, and OBS [2] and other registries build containers which you can then use with podman.
As a bonus, Flatpak uses bubblewrap and portals, so the applications have less access to your data and devices than standard RPM packages, like the standard permissions system on Android and iOS.
podman outdoes docker, while using the same container format, so you aren't losing on the switch, while gaining a little bit better performance and flexibility.
And the most important of all, they don't mess with anything else in your installation, so you don't have to worry about version mismatches and unsupported repositories. Also takes away the blame for the problems away from us ;)
That's the only reasonable way to get Leap with the new packages in a way supported by somebody for free though. As far as I know there are no other plans for up-to-date packages in Leap, even though it has been suggested for quite a while.
Is that really your serious? Is this the future of distributions and especially OpenSuse? You shoot you into your own knees. I do not want new repositories / applications. I would like to have a single package manager as well as. In addition, and the docker was never thought of. Not to mention stability issues and resource waste. And also from other parts of libraries. And not least of security risks. And if I want this all (security risks, multiple existing libraries, resource waste) I can take windows :-( Regards Eric -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Dec 27, 2019 at 00:05, Eric Schirra <ecsos@opensuse.org> wrote:
Is that really your serious? Is this the future of distributions and especially OpenSuse? You shoot you into your own knees. I do not want new repositories / applications. I would like to have a single package manager as well as. In addition, and the docker was never thought of. Not to mention stability issues and resource waste. And also from other parts of libraries. And not least of security risks. And if I want this all (security risks, multiple existing libraries, resource waste) I can take windows :-(
For the desktop, I don't see why this wouldn't be the future. Fedora already builds Flatpaks from RPMs, if OBS could, we probably would also have a project dedicated to building Flatpaks based on our packages. That would actually mean we could ship Flatpaks of Tumbleweed applications without the issues of conflicting RPM package versions, by using a Tumbleweed runtime (one time install, no duplicated libs). Projects like Silverblue (and Kubic Desktop if and when it happens) already focus on usecases where RPM package managers aren't used by the users. Updates are performed automatically, and user only uses Flatpak to install the software they need. It makes the life of the user easier. Not to mention, this would allow SUSE and openSUSE distros to still have "supported" packages, but without the restrictions of the system those are run on. However, if you want Leap to ship Tumbleweed packages, you will have to have multiple versions of libraries, languages and other basic stuff, just to support the premise of mixed version system. It's more work (and probably even more space) than having two versions, and using the newer one to build flatpaks/containers for use with the older one. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Citeren Eric Schirra <ecsos@opensuse.org>:
Am 26. Dezember 2019 16:29:19 MEZ schrieb Robert Kaiser <kairo@kairo.at>:
Neal Gompa schrieb:
On Mon, Dec 23, 2019 at 5:53 PM Eric Schirra <ecsos@opensuse.org> wrote:
When i was Developer i would begin to test when PHP Version ist
releases. Not before.
This ist in my opinion one reason why upstream use more and more flat, SNAP, docker and so on.
In general, it's not very smart to not begin testing as early as possible with the next version of the language that your software is built on...
So are you saying that using Tumbleweed (which is defined as a distro that has all the new versions as soon as possible) is a bad idea "in general"?
Not in General. Applications should be rolling. But in my opinion frameworks should not absolute updated before there are necessary for any application.
If that were the case, we would still have PHP 7.2 in Tumbleweed. Fortunately, that is not the case. Mind you, I don't object to nextcloud not following the PHP development cycle. It just means it has no place in Tumbleweed. We have Leap for that purpose. Tumbleweed promises the latest stable packages, which means we should provide those as soon as is practical. Delaying because one application requires an older version and breaks with a newer version is not a good idea.
Regards Eric -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Arjen de Korte schrieb:
Citeren Eric Schirra <ecsos@opensuse.org>:
Am 26. Dezember 2019 16:29:19 MEZ schrieb Robert Kaiser <kairo@kairo.at>:
Neal Gompa schrieb:
On Mon, Dec 23, 2019 at 5:53 PM Eric Schirra <ecsos@opensuse.org> wrote:
When i was Developer i would begin to test when PHP Version ist
releases. Not before.
This ist in my opinion one reason why upstream use more and more flat, SNAP, docker and so on.
In general, it's not very smart to not begin testing as early as possible with the next version of the language that your software is built on...
So are you saying that using Tumbleweed (which is defined as a distro that has all the new versions as soon as possible) is a bad idea "in general"?
Not in General. Applications should be rolling. But in my opinion frameworks should not absolute updated before there are necessary for any application.
If that were the case, we would still have PHP 7.2 in Tumbleweed. Fortunately, that is not the case. Mind you, I don't object to nextcloud not following the PHP development cycle. It just means it has no place in Tumbleweed. We have Leap for that purpose.
Tumbleweed promises the latest stable packages, which means we should provide those as soon as is practical. Delaying because one application requires an older version and breaks with a newer version is not a good idea.
In all fairness, looks like there are three upstream supported PHP versions at this point in time: https://www.php.net/supported-versions.php So it's perfectly valid for a company to schedule their work accordingly. Also, there is no rule that says we can't have several php versions in TW. So I guess it's mostly a matter of someone actually packaging php in a way to allow 7.3 and 7.4 at the same time. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2019-12-26 16:29, Robert Kaiser wrote:
Neal Gompa schrieb:
On Mon, Dec 23, 2019 at 5:53 PM Eric Schirra <ecsos@opensuse.org> wrote:
When i was Developer i would begin to test when PHP Version ist releases. Not before. This ist in my opinion one reason why upstream use more and more flat, SNAP, docker and so on.
In general, it's not very smart to not begin testing as early as possible with the next version of the language that your software is built on...
So are you saying that using Tumbleweed (which is defined as a distro that has all the new versions as soon as possible) is a bad idea "in general"?
More like: not using Tumbleweed is a bad idea. ;-) Particularly those devs... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
This ist right. Nextcloud 17 does not support PHP 7.4. Perhaps nextcloud 18 will do this. As Arjen wrote zypper say what to do. You can build PHP 7.3 in obs for yourself and switch to PHP 7.3 or you wait for nextcloud 18. Think it is not allways the best to have newest things. Regards Eric Am 23. Dezember 2019 11:44:48 MEZ schrieb "Michael Ströder" <michael@stroeder.com>:
On 12/23/19 10:18 AM, Dominique Leuenberger / DimStar wrote:
The changes contained therein were: [..] * PHP 7.4
Everybody running a nextcloud server on Tumbleweed should be aware that it currently does *not* work with PHP 7.4.
Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (12)
-
Arjen de Korte
-
Axel Braun
-
Dominique Leuenberger / DimStar
-
Eric Schirra
-
Hans-Peter Jansen
-
Jan Engelhardt
-
Ludwig Nussel
-
Michael Ströder
-
Neal Gompa
-
Robert Kaiser
-
Stasiek Michalski
-
Stephan Kulow