At 08:05 PM 1/21/2020, you wrote:
On 1/21/20 10:10 AM, david wrote:
At 08:52 AM 1/21/2020, David G. Miller wrote:
On 1/21/20 9:35 AM, david wrote:
Folks
In a test Centos 8 installation as a guest of VirtualBox on Windows 10, I want to install ffmpeg, and support for exfat. They're not in the standard distribution (as far as I know), so I issue as root:
ÃÂ yum -y --enablerepo rpmfusion-free-updates install ffmpeg fuse-exfat exfat-utils
and that works just fine.ÃÂ The ffmpeg functionality works; I haven't tested exfat yet.ÃÂ However, later, as part of maintenance, I want to get a list of everything that's installed, so I issue
ÃÂ yum list installed
and the following diagnostics occur:
Modular dependency problems:
à Problem 1: conflicting requests à- nothing provides module(perl:5.26) needed by module perl-App-cpanminus:1.7044:8010020191120175858:a9207fc6-0.x86_64 à Problem 2: conflicting requests à- nothing provides module(perl:5.26) needed by module perl-DBD-MySQL:4.046:8010020191114030811:073fa5fe-0.x86_64 à Problem 3: conflicting requests à- nothing provides module(perl:5.26) needed by module perl-DBD-SQLite:1.58:8010020191114033549:073fa5fe-0.x86_64 à Problem 4: conflicting requests à- nothing provides module(perl:5.26) needed by module perl-DBI:1.641:8010020191113222731:16b3ab4d-0.x86_64 à Problem 5: conflicting requests à- nothing provides module(perl:5.26) needed by module perl-YAML:1.24:8010020191114031501:a5949e2e-0.x86_64 Installed Packages
<long list follows> ------------------------------
By the way, cpanm works ok too.
My questions are: What do these diagnostics tell me?ÃÂ What am I supposed to do about it?
Thanks for your help
David
I think its telling you that perl is NOT installed but the listed perl modules are installed although it could be looking for specifically the 5.26 version of perl (since you mentioned the CPAN works).ÃÂ What happens if you issue perl -v?ÃÂ perl gets installed as a dependency of logwatch as an example so a lot of people don't realize that they have perl installed whether they want it or not.
Cheers, Dave
-- "They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty."
-- Benjamin Franklin
Perl is explicitly installed, "perl -v" identifies v5.26.3, and comes from the standard Centos 8 repositories. So, I suspect your interpretation doesn't fit the facts. David K _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Not seeing that here but it appears you are running newer versions of at least perl-DBD-MySQL, perl-DBD-SQLite and perl-DBI (snipped from "yum list installed" on my CentOS 8 VM after running "yum update"):
perl-DBD-MySQL.x86_64Â Â Â Â Â Â Â Â Â Â Â Â
        4.023-6.el7 @anaconda
perl-DBD-SQLite.x86_64Â Â Â Â Â Â Â Â Â Â Â Â
       1.39-3.el7 @anaconda
perl-DBI.x86_64Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
           1.627-4.el7 @anaconda
What repo are you pulling the listed packages from? Is it the same repo as for perl? I'm getting:
Maybe it's worth to have a look a yum.log to see what happened to perl in the history of the installation?
Simon
Simon and others Here's a very simple and hopefully reproducible test-case
Select as your boot ISO: CentOS-8.1.1911-x86_64-dvd1.iso Choose to reclaim all space on the disk Choose 'Minimal Install' as the software selection Connect yourself to the network (I use a wired connection) Don't bother creating a user, just provide your root password. complete the install.
After the reboot, issue as root: yum -y install perl chrony perl-libwww-perl perl-App-cpanminus gcc
When that is complete, issue: yum list installed >nul and you get conflicting requests as follows:
---------------------------- Modular dependency problems:
Problem 1: conflicting requests - nothing provides module(perl:5.26) needed by module perl-App-cpanminus:1.7044:8010020191120175858:a9207fc6-0.x86_64 Problem 2: conflicting requests - nothing provides module(perl:5.26) needed by module perl-YAML:1.24:8010020191114031501:a5949e2e-0.x86_64 ----------------------------
This doesn't seem like the expected results from a clean install. No changes were made in the repo files as supplied on the boot disc.
David
On Jan 22, 2020, at 11:04 AM, david david@daku.org wrote:
After the reboot, issue as root: yum -y install perl chrony perl-libwww-perl perl-App-cpanminus gcc
Thank you for boiling that down. We’ve been seeing the symptom here, too, but the trigger was somewhere inside a thousand-like shell script.
We do similar things to what the above test does, so we have all of those packages installed in our default install except for perl-libwww-perl.
Note that the symptom doesn’t happen on “yum upgrade”, only on certain other operations.
On 1/22/20 11:04 AM, david wrote:
At 08:05 PM 1/21/2020, you wrote:
On 1/21/20 10:10 AM, david wrote:
At 08:52 AM 1/21/2020, David G. Miller wrote:
On 1/21/20 9:35 AM, david wrote:
Folks
In a test Centos 8 installation as a guest of VirtualBox on Windows 10, I want to install ffmpeg, and support for exfat. They're not in the standard distribution (as far as I know), so I issue as root:
 yum -y --enablerepo rpmfusion-free-updates install ffmpeg fuse-exfat exfat-utils
and that works just fine. The ffmpeg functionality works; I haven't tested exfat yet. However, later, as part of
maintenance,
I want to get a list of everything that's installed, so I issue
 yum list installed
and the following diagnostics occur:
Modular dependency problems:
 Problem 1: conflicting requests  - nothing provides module(perl:5.26) needed by module perl-App-cpanminus:1.7044:8010020191120175858:a9207fc6-0.x86_64  Problem 2: conflicting requests  - nothing provides module(perl:5.26) needed by module perl-DBD-MySQL:4.046:8010020191114030811:073fa5fe-0.x86_64  Problem 3: conflicting requests  - nothing provides module(perl:5.26) needed by module perl-DBD-SQLite:1.58:8010020191114033549:073fa5fe-0.x86_64  Problem 4: conflicting requests  - nothing provides module(perl:5.26) needed by module perl-DBI:1.641:8010020191113222731:16b3ab4d-0.x86_64  Problem 5: conflicting requests  - nothing provides module(perl:5.26) needed by module perl-YAML:1.24:8010020191114031501:a5949e2e-0.x86_64 Installed Packages
<long list follows> ------------------------------
By the way, cpanm works ok too.
My questions are: What do these diagnostics tell me? What am I supposed to do
about
it?
Thanks for your help
David
I think its telling you that perl is NOT installed but the listed perl modules are installed although it could be looking for specifically the 5.26 version of perl (since you mentioned the CPAN works). What happens if you issue perl -v? perl gets
installed as
a dependency of logwatch as an example so a lot of people don't realize that they have perl installed whether they want it or not.
Cheers, Dave
-- "They that can give up essential liberty to obtain a little
temporary
safety deserve neither safety nor liberty."
-- Benjamin Franklin
Perl is explicitly installed, "perl -v" identifies v5.26.3, and
comes
from the standard Centos 8 repositories. So, I suspect your interpretation doesn't fit the facts. David K _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Not seeing that here but it appears you are running newer versions
of at
least perl-DBD-MySQL, perl-DBD-SQLite and perl-DBI (snipped from "yum list installed" on my CentOS 8 VM after running "yum update"):
perl-DBD-MySQL.x86_64Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
4.023-6.el7 @anaconda
perl-DBD-SQLite.x86_64Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
1.39-3.el7 @anaconda
perl-DBI.x86_64Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
1.627-4.el7 @anaconda
What repo are you pulling the listed packages from? Is it the
same repo
as for perl? I'm getting:
Maybe it's worth to have a look a yum.log to see what happened to perl in the history of the installation?
Simon
Simon and others Here's a very simple and hopefully reproducible test-case
Select as your boot ISO: CentOS-8.1.1911-x86_64-dvd1.iso Choose to reclaim all space on the disk Choose 'Minimal Install' as the software selection Connect yourself to the network (I use a wired connection) perl-App-cpanminus Don't bother creating a user, just provide your root password. complete the install.
After the reboot, issue as root: yum -y install perl chrony perl-libwww-perl perl-App-cpanminus gcc
When that is complete, issue: yum list installed >nul and you get conflicting requests as follows:
Modular dependency problems:
Problem 1: conflicting requests - nothing provides module(perl:5.26) needed by module perl-App-cpanminus:1.7044:8010020191120175858:a9207fc6-0.x86_64 Problem 2: conflicting requests - nothing provides module(perl:5.26) needed by module perl-YAML:1.24:8010020191114031501:a5949e2e-0.x86_64
This doesn't seem like the expected results from a clean install. No changes were made in the repo files as supplied on the boot disc.
David
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
OK. Recreated the issue here.
Interestingly, perl-DBI and perl-DBD-SQLite did not have an issue with "nothing provides module(perl:5.26)" until I installed perl-App-cpanimus and perl-YAML which pulled in perl 5.26 (and ~90 other dependencies). They now show up as not being able to find module(perl:5.26) when I do a yum list installed.
Also, perl-App-cpanimus and perl-YAML report perl 5.26 as not provided and these are the modules that pulled in perl 5.26. I looked at the appropriate provides and requires for each package with rpm and don't see anything that jumps out at me.
Have you tried using these modules in a perl program? Wondering if it's a dnf or rpm dependency coding problem but everything works when you try to use it. A missing dependency should cause the install to fail.
Cheers, Dave
Simon and others Here's a very simple and hopefully reproducible test-case
Select as your boot ISO: CentOS-8.1.1911-x86_64-dvd1.iso Choose to reclaim all space on the disk Choose 'Minimal Install' as the software selection Connect yourself to the network (I use a wired connection) Don't bother creating a user, just provide your root password. complete the install.
After the reboot, issue as root: yum -y install perl chrony perl-libwww-perl perl-App-cpanminus gcc
When that is complete, issue: yum list installed >nul and you get conflicting requests as follows:
Modular dependency problems:
Problem 1: conflicting requests - nothing provides module(perl:5.26) needed by module perl-App-cpanminus:1.7044:8010020191120175858:a9207fc6-0.x86_64 Problem 2: conflicting requests - nothing provides module(perl:5.26) needed by module perl-YAML:1.24:8010020191114031501:a5949e2e-0.x86_64
This doesn't seem like the expected results from a clean install. No changes were made in the repo files as supplied on the boot disc.
I would agree. I have the same behavior in a Redhat 8 development system, so it's not a problem with the Centos build. I have not added any repositories other then the Redhat codeready-builder-for-rhel-8-x86_64-rpms. I original installed 8.0 and have applied all updates. I did not notice the problem until recently.
# dnf list installed | head -20 Updating Subscription Management repositories. Modular dependency problems:
Problem 1: conflicting requests - nothing provides module(perl:5.26) needed by module perl-DBD-SQLite:1.58:8010020190322125518:073fa5fe-0.x86_64 Problem 2: conflicting requests - nothing provides module(perl:5.26) needed by module perl-DBI:1.641:8010020190322130042:16b3ab4d-0.x86_64 Installed Packages GConf2.x86_64 3.2.6-22.el8 @AppStream ModemManager.x86_64 1.10.4-1.el8 @rhel-8-for-x86_64-baseos-rpms . . .
David
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 1/23/20 2:29 PM, Nataraj wrote:
I would agree. I have the same behavior in a Redhat 8 development system, so it's not a problem with the Centos build. I have not added any repositories other then the Redhat codeready-builder-for-rhel-8-x86_64-rpms. I original installed 8.0 and have applied all updates. I did not notice the problem until recently.
# dnf list installed | head -20 Updating Subscription Management repositories. Modular dependency problems:
Problem 1: conflicting requests
- nothing provides module(perl:5.26) needed by module perl-DBD-SQLite:1.58:8010020190322125518:073fa5fe-0.x86_64
Problem 2: conflicting requests
- nothing provides module(perl:5.26) needed by module perl-DBI:1.641:8010020190322130042:16b3ab4d-0.x86_64
Installed Packages GConf2.x86_64 3.2.6-22.el8 @AppStream ModemManager.x86_64 1.10.4-1.el8 @rhel-8-for-x86_64-baseos-rpms . . .
This appears to be a known problem. I found the following workaround on the redhat site. (you need to login and it might require either a license or a developer subscription (which is what I have).
https://access.redhat.com/solutions/4678261
The instructions were a little unclear to me, but I did the following and it appears to have solved the problem.
root@rhel8mail nataraj]# dnf check Updating Subscription Management repositories. Modular dependency problems:
Problem 1: conflicting requests - nothing provides module(perl:5.26) needed by module perl-DBD-SQLite:1.58:8010020190322125518:073fa5fe-0.x86_64 Problem 2: conflicting requests - nothing provides module(perl:5.26) needed by module perl-DBI:1.641:8010020190322130042:16b3ab4d-0.x86_64
[root@rhel8mail nataraj]# yum module enable perl:5.26 Updating Subscription Management repositories. Last metadata expiration check: 1:02:48 ago on Thu 23 Jan 2020 01:42:25 PM PST. Dependencies resolved. ================================================================================ Package Architecture Version Repository Size ================================================================================ Enabling module streams: perl 5.26
Transaction Summary ================================================================================
Is this ok [y/N]: y Complete! [root@rhel8mail nataraj]# dnf check Updating Subscription Management repositories. [root@rhel8mail nataraj]#
At 03:46 PM 1/23/2020, Nataraj wrote:
On 1/23/20 2:29 PM, Nataraj wrote:
I would agree. I have the same behavior in a Redhat 8 development system, so it's not a problem with the Centos build. I have not added any repositories other then the Redhat codeready-builder-for-rhel-8-x86_64-rpms. I original installed 8.0 and have applied all updates. I did not notice the problem until recently.
# dnf list installed | head -20 Updating Subscription Management repositories. Modular dependency problems:
Problem 1: conflicting requests
- nothing provides module(perl:5.26) needed
by module perl-DBD-SQLite:1.58:8010020190322125518:073fa5fe-0.x86_64
Problem 2: conflicting requests
- nothing provides module(perl:5.26) needed
by module perl-DBI:1.641:8010020190322130042:16b3ab4d-0.x86_64
Installed Packages
GConf2.x86_64 3.2.6-22.el8 @AppStream
ModemManager.x86_64 1.10.4-1.el8 @rhel-8-for-x86_64-baseos-rpms
. . .
This appears to be a known problem. I found the following workaround on the redhat site. (you need to login and it might require either a license or a developer subscription (which is what I have).
https://access.redhat.com/solutions/4678261
The instructions were a little unclear to me, but I did the following and it appears to have solved the problem.
root@rhel8mail nataraj]# dnf check Updating Subscription Management repositories. Modular dependency problems:
Problem 1: conflicting requests
- nothing provides module(perl:5.26) needed
by module perl-DBD-SQLite:1.58:8010020190322125518:073fa5fe-0.x86_64 Problem 2: conflicting requests
- nothing provides module(perl:5.26) needed
by module perl-DBI:1.641:8010020190322130042:16b3ab4d-0.x86_64
[root@rhel8mail nataraj]# yum module enable perl:5.26 Updating Subscription Management repositories. Last metadata expiration check: 1:02:48 ago on Thu 23 Jan 2020 01:42:25 PM PST. Dependencies resolved. ================================================================================ Package Architecture Version Repository Size ================================================================================ Enabling module streams: perl 5.26
Transaction Summary
Is this ok [y/N]: y Complete! [root@rhel8mail nataraj]# dnf check Updating Subscription Management repositories. [root@rhel8mail nataraj]#
>>>> SOLVED <<<<<<<<<<<<<
Nataraj
Yes, this does eliminate the diagnostic. Exactly what else it does I don't know, because I haven't grasped the concept of the module streams yet. One thing bothers me, tho.....
Apparently, the problem was identified and workaround described in mid December. I encountered the problem in early January, and Google searches gave me no clue. Apparently, the RedHat forum on which this workaround was described didn't show up, and if it did, I couldn't access it. It was your useful "feet in both RedHat and Centos" that made the link, but after a few people spent considerable time trying to help. If I might be so bold as to suggest that somehow workarounds for RedHat problems that would show up in the corresponding CentOS release be made visible to the Centos community to avoid duplication of effort.
Thanks for the research.
David Kurn
On 1/23/20 4:20 PM, david wrote:
At 03:46 PM 1/23/2020, Nataraj wrote:
On 1/23/20 2:29 PM, Nataraj wrote:
I would agree. I have the same behavior in a Redhat 8 development system, so it's not a problem with the Centos build. I have not
added
any repositories other then the Redhat codeready-builder-for-rhel-8-x86_64-rpms. I original installed 8.0 and have applied all updates. I did not notice the problem until
recently.
# dnf list installed | head -20 Updating Subscription Management repositories. Modular dependency problems:
Problem 1: conflicting requests - nothing provides module(perl:5.26) needed by module
perl-DBD-SQLite:1.58:8010020190322125518:073fa5fe-0.x86_64
Problem 2: conflicting requests - nothing provides module(perl:5.26) needed by module
perl-DBI:1.641:8010020190322130042:16b3ab4d-0.x86_64
Installed Packages GConf2.x86_64 3.2.6-22.el8 @AppStream ModemManager.x86_64 1.10.4-1.el8 @rhel-8-for-x86_64-baseos-rpms . . .
This appears to be a known problem. I found the following workaround on the redhat site. (you need to login and it might require either a license or a developer subscription (which is what I have).
https://access.redhat.com/solutions/4678261
The instructions were a little unclear to me, but I did the following and it appears to have solved the problem.
root@rhel8mail nataraj]# dnf check Updating Subscription Management repositories. Modular dependency problems:
Problem 1: conflicting requests - nothing provides module(perl:5.26) needed by module perl-DBD-SQLite:1.58:8010020190322125518:073fa5fe-0.x86_64 Problem 2: conflicting requests - nothing provides module(perl:5.26) needed by module perl-DBI:1.641:8010020190322130042:16b3ab4d-0.x86_64
[root@rhel8mail nataraj]# yum module enable perl:5.26 Updating Subscription Management repositories. Last metadata expiration check: 1:02:48 ago on Thu 23 Jan 2020 01:42:25 PM PST. Dependencies resolved. ================================================================================
Package Architecture Version Repository Size ================================================================================
Enabling module streams: perl 5.26
Transaction Summary
Is this ok [y/N]: y Complete! [root@rhel8mail nataraj]# dnf check Updating Subscription Management repositories. [root@rhel8mail nataraj]#
>>>>> SOLVED <<<<<<<<<<<<<
Nataraj
Yes, this does eliminate the diagnostic. Exactly what else it does I don't know, because I haven't grasped the concept of the module streams yet. One thing bothers me, tho.....
My sense is it just renables the module (which I believe was already enabled), possibly setting a bit somewhere that was not previously set or was set incorrectly.
Apparently, the problem was identified and workaround described in mid December. I encountered the problem in early January, and Google searches gave me no clue. Apparently, the RedHat forum on which this workaround was described didn't show up, and if it did, I couldn't access it. It was your useful "feet in both RedHat and Centos" that made the link, but after a few people spent considerable time trying to help. If I might be so bold as to suggest that somehow workarounds for RedHat problems that would show up in the corresponding CentOS release be made visible to the Centos community to avoid duplication of effort.
The redhat access page comes up in both google and duckduckgo when I put in the entire 4 lines of the error message. You still have to login to see the solution.
https://www.google.com/search?client=ubuntu&channel=fs&q=+Problem+1%...
Other than that you could create a login on the redhat site and register as a developer (free of charge) and have access to some of their online resources including the access knowledgebase.
I am mostly a CentOS user, and installed redhat 8 so I could start working on my applications before CentOS 8 was released.
Nataraj
<lots snipped>
The redhat access page comes up in both google and duckduckgo when I put in the entire 4 lines of the error message. You still have to login to see the solution.
https://www.google.com/search?client=ubuntu&channel=fs&q=+Problem+1%...
Other than that you could create a login on the redhat site and register as a developer (free of charge) and have access to some of their online resources including the access knowledgebase.
I am mostly a CentOS user, and installed redhat 8 so I could start working on my applications before CentOS 8 was released.
Nataraj
I have a free subscription, but still can't get to the solution page. Oh well.
David
<lots snipped>
The redhat access page comes up in both google and duckduckgo when I put in the entire 4 lines of the error message. You still have to login to see the solution.
https://www.google.com/search?client=ubuntu&channel=fs&q=+Problem+1%...
Other than that you could create a login on the redhat site and register as a developer (free of charge) and have access to some of their online resources including the access knowledgebase.
I am mostly a CentOS user, and installed redhat 8 so I could start working on my applications before CentOS 8 was released.
Nataraj
I have a free subscription, but still can't get to the solution page. Oh well.
I've never really understood how hiding those solutions behind a wall is a good thing in/for the OpenSource world. Looks like I'm not alone :-)
Simon
On 1/24/20 8:02 AM, Simon Matter via CentOS wrote:
<lots snipped>
The redhat access page comes up in both google and duckduckgo when I put in the entire 4 lines of the error message. You still have to login to see the solution.
https://www.google.com/search?client=ubuntu&channel=fs&q=+Problem+1%...
Other than that you could create a login on the redhat site and register as a developer (free of charge) and have access to some of their online resources including the access knowledgebase.
I am mostly a CentOS user, and installed redhat 8 so I could start working on my applications before CentOS 8 was released.
Nataraj
I have a free subscription, but still can't get to the solution page. Oh well.
I've never really understood how hiding those solutions behind a wall is a good thing in/for the OpenSource world. Looks like I'm not alone :-)
A good thing is the ability for someone to be able to pay people actual money so that CentOS can actually exist. There is no CentOS (or Scientfic Linux or Oracle Linux) without RHEL. There is no RHEL if Red Hat can not make money.
If one is not smart enough to support their own install .. the answer is .. buy RHEL.
On Jan 30, 2020, at 9:37 AM, Johnny Hughes johnny@centos.org wrote:
On 1/24/20 8:02 AM, Simon Matter via CentOS wrote:
I've never really understood how hiding those solutions behind a wall is a good thing in/for the OpenSource world. Looks like I'm not alone :-)
A good thing is the ability for someone to be able to pay people actual money so that CentOS can actually exist. There is no CentOS (or Scientfic Linux or Oracle Linux) without RHEL. There is no RHEL if Red Hat can not make money.
If one is not smart enough to support their own install .. the answer is .. buy RHEL.
While I think I agree with you in principle, this case doesn’t really fall into the category you’re outlining, for several reasons.
1. dnf is complaining that "nothing provides module(perl:5.26)” when Perl is evidently installed. How did it get there if nothing provides it? I don’t see how this is anything but a packaging bug. If the financial stability of the Red Hat subsidiary of IBM, Inc. depends on people paying them for advice on how to get around broad-based bugs Red Hat created — or at least allowed to pass QA — that’s a perverse incentive that will ultimately damage the subsidiary.
2. I would think that the “support” you speak of, the lifeblood of the Red Hat subsidiary, is principally one-to-one, where the recipient is getting value they could not easily receive any other way. That should exclude problems so common that they end up in the knowledge base. That’s one-to-many, which means the per-recipient value of the information is amortized.
The bottom line is that I think the community here is acting as an auxiliary QA arm for Red Hat, benefiting their paying customers. Our payment? I’ll take some more CentOS, thanks. :)
On 1/24/20 8:02 AM, Simon Matter via CentOS wrote:
<lots snipped>
The redhat access page comes up in both google and duckduckgo when I put in the entire 4 lines of the error message. You still have to login to see the solution.
https://www.google.com/search?client=ubuntu&channel=fs&q=+Problem+1%...
Other than that you could create a login on the redhat site and register as a developer (free of charge) and have access to some of their online resources including the access knowledgebase.
I am mostly a CentOS user, and installed redhat 8 so I could start working on my applications before CentOS 8 was released.
Nataraj
I have a free subscription, but still can't get to the solution page. Oh well.
I've never really understood how hiding those solutions behind a wall is a good thing in/for the OpenSource world. Looks like I'm not alone :-)
A good thing is the ability for someone to be able to pay people actual money so that CentOS can actually exist. There is no CentOS (or Scientfic Linux or Oracle Linux) without RHEL. There is no RHEL if Red Hat can not make money.
I can not agree here. To make this clear, I'm not from the "everything must be free to consume" crowd just in case it sounds so. But when we talk about money and RedHat my POV is this:
1) RedHat has made quite a lot of money through me in the past decades! Of course not from my personal purchases but from those companies who bought from RedHat because I was behind the projects.
2) RedHat includes the work of thousands of people around the world without paying a cent to most of them. One of them is me, work from me can be found in RedHat products and it's from my personal work as well as work I did for companies who agreed to keep this work free for everybody as well.
I never asked a cent from RedHat and don't expect it. I only don't like how they've built walls to prevent me from having access to some useful tips and tricks which can make my life easier.
That's why I don't like these walls even if you can climb them for free somehow if you learn how.
Regards, Simon
On 1/24/20 8:02 AM, Simon Matter via CentOS wrote:
<lots snipped>
The redhat access page comes up in both google and duckduckgo when I put in the entire 4 lines of the error message. You still have to login to see the solution.
https://www.google.com/search?client=ubuntu&channel=fs&q=+Problem+1%...
Other than that you could create a login on the redhat site and register as a developer (free of charge) and have access to some of their online resources including the access knowledgebase.
I am mostly a CentOS user, and installed redhat 8 so I could start working on my applications before CentOS 8 was released.
Nataraj
I have a free subscription, but still can't get to the solution page. Oh well.
I've never really understood how hiding those solutions behind a wall is a good thing in/for the OpenSource world. Looks like I'm not alone :-)
A good thing is the ability for someone to be able to pay people actual money so that CentOS can actually exist. There is no CentOS (or Scientfic Linux or Oracle Linux) without RHEL. There is no RHEL if Red Hat can not make money.
And there is no RedHat if thousands of developers would not allow RedHat to consume their work for free. Creators of free software didn't build walls around their projects. Do you thinks it's a good thing that RedHat does exactly this with their tip and tricks (KB)? I believe it can damage RedHat because a lot of people at the source of RedHats products don't appreciate it at all.
Regards, Simon
On 1/30/20 10:08 PM, Simon Matter via CentOS wrote:
On 1/24/20 8:02 AM, Simon Matter via CentOS wrote:
<lots snipped>
The redhat access page comes up in both google and duckduckgo when I put in the entire 4 lines of the error message. You still have to login to see the solution.
https://www.google.com/search?client=ubuntu&channel=fs&q=+Problem+1%...
Other than that you could create a login on the redhat site and register as a developer (free of charge) and have access to some of their online resources including the access knowledgebase.
I am mostly a CentOS user, and installed redhat 8 so I could start working on my applications before CentOS 8 was released.
Nataraj
I have a free subscription, but still can't get to the solution page. Oh well.
I've never really understood how hiding those solutions behind a wall is a good thing in/for the OpenSource world. Looks like I'm not alone :-)
A good thing is the ability for someone to be able to pay people actual money so that CentOS can actually exist. There is no CentOS (or Scientfic Linux or Oracle Linux) without RHEL. There is no RHEL if Red Hat can not make money.
And there is no RedHat if thousands of developers would not allow RedHat to consume their work for free. Creators of free software didn't build walls around their projects. Do you thinks it's a good thing that RedHat does exactly this with their tip and tricks (KB)? I believe it can damage RedHat because a lot of people at the source of RedHats products don't appreciate it at all.
But you are not talking about access to source code here .. you are taking about access to a paid support website for customers for knowledge base articles.
The Source Code .. heck, even Binary rpms, exist and were installed in this case .. completely for free from CentOS Linux. What is being complained about is no access to documentation for paid customers to fix issues with RHEL .. not to fix something in CentOS Linux. This list and wiki.centos.org and forums.centos.org are where the CentOS Community can develop open source, free documentation for these issues for CentOS Linux.
Red Hat certainly understands open source .. as shown by this:
https://www.infoworld.com/article/3253948/who-really-contributes-to-open-sou... (github commits)
and this:
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Git-Stats-EOY2... (kernel commits)
The same holds true for any number of important projects .. gcc, etc.
I love open source .. that is why I have been doing CentOS binaries since 2004. I totally believe in open source. It has. in fact, taken over the world of Information Technology much to my delight.
Thanks, Johnny Hughes
On 24/01/20 4:47 pm, david wrote:
I have a free subscription, but still can't get to the solution page. Oh well.
I can confirm it works with a free sub. It may be that yours is expired, you have to renew it every year.
Peter
-
david -
David G. Miller -
Johnny Hughes -
Nataraj -
Peter -
Simon Matter -
Warren Young