Re: [CentOS] Announcing Open-sourced & Community-Driven RHEL Fork by CloudLinux
Considering that it is being spearheaded by the originator of CentOS, with the original goals of CentOS (before being swallowed by RH then IBM) as a stable, enterprise OS, I'm putting my support behind Rocky rockylinux.org and would urge others to do the same. I've been around the Linux world for many years and looked at and tried many distributions. Most of them are either unstable or bloated, or both. The only thing I'd trust Oracle to do is screw the computing community any way possible. On 12/11/2020 7:01 AM, Nicolas Kovacs wrote: Le 11/12/2020 à 14:09, Liam O'Toole a écrit : OEL = Oracle Enterprise Linux? There is no reason in heaven or hell to trust them. As far as I'm concerned, they're the good guys now. :o) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] https://blog.centos.org/2020/12/future-is-centos-stream/
Look at Rocky Linux rockylinux.org It is set to become what CentOS was before it was sucked in by RH and sold to IBM, a Community Enterprise OS. On 12/8/2020 8:15 AM, Pete Biggs wrote: Forgive a bit of cynicism ... On Tue, 2020-12-08 at 09:06 -0500, Rich Bowen wrote: The future of the CentOS Project is CentOS Stream, and over the next year we’ll be shifting focus from CentOS Linux, the rebuild of Red Hat Enterprise Linux (RHEL), to CentOS Stream, which tracks just ahead of a current RHEL release. CentOS Linux 8, as a rebuild of RHEL 8, will end at the end of 2021. CentOS Stream continues after that date, serving as the upstream (development) branch of Red Hat Enterprise Linux. "If you want to keep using RHEL for free, you will have to put up with making sure that our paying customers get better quality releases" Meanwhile, we understand many of you are deeply invested in CentOS Linux 7, and we’ll continue to produce that version through the remainder of the RHEL 7 life cycle. https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates "If you really want to have a stable release for free, stick to 7" CentOS Stream will also be the centerpiece of a major shift in collaboration among the CentOS Special Interest Groups (SIGs). This ensures SIGs are developing and testing against what becomes the next version of RHEL. This also provides SIGs a clear single goal, rather than having to build and test for two releases. It gives the CentOS contributor community a great deal of influence in the future of RHEL. "CentOS will become the developer playground" And it removes confusion around what “CentOS” means in the Linux distribution ecosystem. Was there any confusion? If there is, then it's caused by the introduction of things like "CentOS Stream". There was never any confusion when it was a straight rebuild. When CentOS Linux 8 (the rebuild of RHEL8) ends, your best option will be to migrate to CentOS Stream 8, which is a small delta from CentOS Linux 8, and has regular updates like traditional CentOS Linux releases. If you are using CentOS Linux 8 in a production environment, and are concerned that CentOS Stream will not meet your needs, we encourage you to contact Red Hat about options. "If you want a production environment, pay for it" We have an FAQ - https://centos.org/distro-faq/ - to help with your information and planning needs, as you figure out how this shift of project focus might affect you. The FAQ generally says "if you want a RHEL environment, then pay for it" [See also: Red Hat's perspective on this. https://www.redhat.com/en/blog/centos-stream-building-innovative-future-enterprise-linux] Red Hat's perspective is "CentOS is ours now; IBM have told us to make sure it's pulling its weight or we aren't allowed to put any resources into it" So as far as I can see all the RHEL rebuilds are dead now - WhiteBox, Scientific Linux, now CentOS. Are there any left? P. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] kernel/iptables state match support
I just noticed that the stock Centos7 kernels no longer include state/match support. What happened and what can be done to get it? --Richard ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7 and php 5.5
It is definitely supposed to be for EL7 # Repository: http://rpms.remirepo.net/ # Blog: http://blog.remirepo.net/ # Forum: http://forum.remirepo.net/ [remi] name=Remi's RPM repository for Enterprise Linux 7 - $basearch #baseurl=http://rpms.remirepo.net/enterprise/7/remi/$basearch/ mirrorlist=http://rpms.remirepo.net/enterprise/7/remi/mirror enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-remi [remi-php55] name=Remi's PHP 5.5 RPM repository for Enterprise Linux 7 - $basearch #baseurl=http://rpms.remirepo.net/enterprise/7/php55/$basearch/ mirrorlist=http://rpms.remirepo.net/enterprise/7/php55/mirror # NOTICE: common dependencies are in "remi-safe" enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-remi [remi-php56] name=Remi's PHP 5.6 RPM repository for Enterprise Linux 7 - $basearch #baseurl=http://rpms.remirepo.net/enterprise/7/php56/$basearch/ mirrorlist=http://rpms.remirepo.net/enterprise/7/php56/mirror # NOTICE: common dependencies are in "remi-safe" enabled=0 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-remi On 8/25/2016 8:08 AM, Alice Wonder wrote: On 08/25/2016 07:07 AM, Alice Wonder wrote: Looks like you are trying to install packages built for EL6 in EL7 I'm fairly certain Remi has EL7 packages for PHP 7. That should read "PHP packages for EL7" ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Centos 7 and php 5.5
I am hoping that the wisdom of the group here can at least point me in the right direction. I have a Centos7 server that I need to upgrade php from 5.4 to 5.5. I've tried several tutorials to add the remi repository and enable php55, but I always end up at the same result: Error: Package: php-5.5.38-1.el6.remi.x86_64 (remi-php55) Requires: httpd-mmn = 20051115 Installed: httpd-2.4.6-40.el7.centos.4.x86_64 (@updates) httpd-mmn = 20120211 httpd-mmn = 20120211x8664 httpd-mmn = 20120211-x86-64 Available: httpd-2.4.6-40.el7.centos.x86_64 (base) httpd-mmn = 20120211x8664 httpd-mmn = 20120211-x86-64 httpd-mmn = 20120211 Available: httpd-2.4.6-40.el7.centos.1.x86_64 (updates) httpd-mmn = 20120211x8664 httpd-mmn = 20120211-x86-64 httpd-mmn = 20120211 Error: Package: php-pecl-jsonc-1.3.10-1.el7.remi.5.4.x86_64 (remi) Requires: php(api) = 20100412-64 Removing: php-common-5.4.45-11.el7.remi.x86_64 (@remi) php(api) = 20100412-64 Updated By: php-common-5.5.38-1.el6.remi.x86_64 (remi-php55) php(api) = 20121113-64 Available: php-common-5.4.16-36.el7_1.x86_64 (base) php(api) = 20100412-64 Available: php-common-5.4.16-36.1.el7_2.1.x86_64 (updates) php(api) = 20100412-64 Available: php-common-5.4.16-36.3.el7_2.x86_64 (updates) php(api) = 20100412-64 Available: php-common-5.4.45-10.el7.remi.x86_64 (remi) php(api) = 20100412-64 Available: php-common-5.5.37-1.el6.remi.x86_64 (remi-php55) php(api) = 20121113-64 Error: Package: php-pecl-jsonc-1.3.10-1.el7.remi.5.4.x86_64 (remi) Requires: php(zend-abi) = 20100525-64 Removing: php-common-5.4.45-11.el7.remi.x86_64 (@remi) php(zend-abi) = 20100525-64 Updated By: php-common-5.5.38-1.el6.remi.x86_64 (remi-php55) php(zend-abi) = 20121212-64 Available: php-common-5.4.16-36.el7_1.x86_64 (base) php(zend-abi) = 20100525-64 Available: php-common-5.4.16-36.1.el7_2.1.x86_64 (updates) php(zend-abi) = 20100525-64 Available: php-common-5.4.16-36.3.el7_2.x86_64 (updates) php(zend-abi) = 20100525-64 Available: php-common-5.4.45-10.el7.remi.x86_64 (remi) php(zend-abi) = 20100525-64 Available: php-common-5.5.37-1.el6.remi.x86_64 (remi-php55) php(zend-abi) = 20121212-64 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest If I try --skip-broken, I get: Packages skipped because of dependency problems: gd-last-2.2.3-1.el7.remi.x86_64 from remi libpng12-1.2.50-7.el7_2.x86_64 from updates libzip-last-1.1.3-1.el7.remi.x86_64 from remi php-5.5.38-1.el6.remi.x86_64 from remi-php55 php-cli-5.5.38-1.el6.remi.x86_64 from remi-php55 php-common-5.5.38-1.el6.remi.x86_64 from remi-php55 php-gd-5.5.38-1.el6.remi.x86_64 from remi-php55 php-mbstring-5.5.38-1.el6.remi.x86_64 from remi-php55 php-mcrypt-5.5.38-1.el6.remi.x86_64 from remi-php55 php-mysqlnd-5.5.38-1.el6.remi.x86_64 from remi-php55 php-pdo-5.5.38-1.el6.remi.x86_64 from remi-php55 php-pecl-jsonc-1.3.10-1.el7.remi.5.4.x86_64 from remi php-pecl-zip-1.13.4-1.el6.remi.5.5.x86_64 from remi-php55 php-process-5.5.38-1.el6.remi.x86_64 from remi-php55 php-xml-5.5.38-1.el6.remi.x86_64 from remi-php55 Error: Multilib version problems found. This often means that the root cause is something else and multilib version checking is just pointing out that there is a problem. Eg.: 1. You have an upgrade for php-common which is missing some dependency that another package requires. Yum is trying to solve this by installing an older version of php-common of the different architecture. If you exclude the bad architecture yum will tell you what the root cause is (which package requires what). You can try redoing the upgrade with --exclude php-common.otherarch ... this should give you an error message showing the root cause of the problem. 2. You have multiple architectures of php-common installed, but yum can only see an upgrade for one of those architectures. If you don't want/need both architectures anymore then you can remove the one with the missing update and everything will work. 3. You have duplicate versions of php-common installed already. You can use "yum check" to get yum show these errors. ...you can also use --setopt=protected_multilib=false to remove this checking, however this
