AIX Open Source

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

Doesnt work:

p9aixdev4-openxl AIX-powerpc pmilosla$ sudo dnf update
Segmentation fault (core dumped) [=== ] --- B/s | 0 B --:-- ETA
p9aixdev4-openxl AIX-powerpc pmilosla$

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

Doesnt work:

p9aixdev4-openxl AIX-powerpc pmilosla$ sudo dnf update
Segmentation fault (core dumped) [=== ] --- B/s | 0 B --:-- ETA
p9aixdev4-openxl AIX-powerpc pmilosla$

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

Doesnt work:

p9aixdev4-openxl AIX-powerpc pmilosla$ sudo dnf update
Segmentation fault (core dumped) [=== ] --- B/s | 0 B --:-- ETA
p9aixdev4-openxl AIX-powerpc pmilosla$

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

Hi Sangamesh,

Any update on permanent solution of this issue. 

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

Hi Saurabh

We are doing the testing and hopefully we will be able to have all update packages available in a month.

Hi Sangamesh,

Any update on permanent solution of this issue. 

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

Sangamesh,

does 
"in a month" mean DNF will be still be 3.7-based, just  linked w/o rtl or will it be python3.9 based?
We don't  have a problem with current linkage,  but we do have a huge one with python3.7,
community support for which expires in 2 months, 3 weeks.

We aren't allowed to use expired pythons here.

Thought you said "end of March" tentatively for python3 == python3.9,  but I'm not sure.

So what are you DNF with python3.9 plans?

Thanks,

Sergey Tulyakov,
Sr SRE,  Verisign 

------------------------------
Sergey Tulyakov

Original Message:
Sent: Fri March 24, 2023 08:35 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Hi Saurabh

We are doing the testing and hopefully we will be able to have all update packages available in a month.

------------------------------
SANGAMESH

Original Message:
Sent: Thu March 23, 2023 11:00 AM
From: Saurabh Johri
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Hi Sangamesh,

Any update on permanent solution of this issue. 

------------------------------
Saurabh Johri

Original Message:
Sent: Thu December 22, 2022 06:06 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

------------------------------
SANGAMESH
------------------------------

Hi Sergey,

It will be with python3.9 for DNF and other toolbox packages.

We are waiting for an approval before we start uploading python3.9 packages.

------------------------------
SANGAMESH
------------------------------

Original Message:
Sent: Thu April 06, 2023 01:42 PM
From: Sergey Tulyakov
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Sangamesh,

does 
"in a month" mean DNF will be still be 3.7-based, just  linked w/o rtl or will it be python3.9 based?
We don't  have a problem with current linkage,  but we do have a huge one with python3.7,
community support for which expires in 2 months, 3 weeks.

We aren't allowed to use expired pythons here.

Thought you said "end of March" tentatively for python3 == python3.9,  but I'm not sure.

So what are you DNF with python3.9 plans?

Thanks,

Sergey Tulyakov,
Sr SRE,  Verisign 

------------------------------
Sergey Tulyakov

Original Message:
Sent: Fri March 24, 2023 08:35 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Hi Saurabh

We are doing the testing and hopefully we will be able to have all update packages available in a month.

------------------------------
SANGAMESH

Original Message:
Sent: Thu March 23, 2023 11:00 AM
From: Saurabh Johri
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Hi Sangamesh,

Any update on permanent solution of this issue. 

------------------------------
Saurabh Johri

Original Message:
Sent: Thu December 22, 2022 06:06 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

------------------------------
SANGAMESH
------------------------------

Hi Sergey,

It will be with python3.9 for DNF and other toolbox packages.

We are waiting for an approval before we start uploading python3.9 packages.

------------------------------
SANGAMESH

Original Message:
Sent: Thu April 06, 2023 01:42 PM
From: Sergey Tulyakov
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Sangamesh,

does 
"in a month" mean DNF will be still be 3.7-based, just  linked w/o rtl or will it be python3.9 based?
We don't  have a problem with current linkage,  but we do have a huge one with python3.7,
community support for which expires in 2 months, 3 weeks.

We aren't allowed to use expired pythons here.

Thought you said "end of March" tentatively for python3 == python3.9,  but I'm not sure.

So what are you DNF with python3.9 plans?

Thanks,

Sergey Tulyakov,
Sr SRE,  Verisign 

------------------------------
Sergey Tulyakov

Original Message:
Sent: Fri March 24, 2023 08:35 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Hi Saurabh

We are doing the testing and hopefully we will be able to have all update packages available in a month.

------------------------------
SANGAMESH

Original Message:
Sent: Thu March 23, 2023 11:00 AM
From: Saurabh Johri
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Hi Sangamesh,

Any update on permanent solution of this issue. 

------------------------------
Saurabh Johri

Original Message:
Sent: Thu December 22, 2022 06:06 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

------------------------------
SANGAMESH
------------------------------

We are hoping to have everything sorted in 1 to 1.5 months. 

Hi Sergey,

It will be with python3.9 for DNF and other toolbox packages.

We are waiting for an approval before we start uploading python3.9 packages.

------------------------------
SANGAMESH

Original Message:
Sent: Thu April 06, 2023 01:42 PM
From: Sergey Tulyakov
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Sangamesh,

does 
"in a month" mean DNF will be still be 3.7-based, just  linked w/o rtl or will it be python3.9 based?
We don't  have a problem with current linkage,  but we do have a huge one with python3.7,
community support for which expires in 2 months, 3 weeks.

We aren't allowed to use expired pythons here.

Thought you said "end of March" tentatively for python3 == python3.9,  but I'm not sure.

So what are you DNF with python3.9 plans?

Thanks,

Sergey Tulyakov,
Sr SRE,  Verisign 

------------------------------
Sergey Tulyakov

Original Message:
Sent: Fri March 24, 2023 08:35 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Hi Saurabh

We are doing the testing and hopefully we will be able to have all update packages available in a month.

------------------------------
SANGAMESH

Original Message:
Sent: Thu March 23, 2023 11:00 AM
From: Saurabh Johri
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Hi Sangamesh,

Any update on permanent solution of this issue. 

------------------------------
Saurabh Johri

Original Message:
Sent: Thu December 22, 2022 06:06 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

------------------------------
SANGAMESH
------------------------------

Original Message:
Sent: 4/7/2023 10:00:00 AM
From: SANGAMESH MALLAYYA
Subject: RE: Recent DNF and YUM issues with newer python3 and curl builds

We are hoping to have everything sorted in 1 to 1.5 months. 

------------------------------
SANGAMESH

Original Message:
Sent: Fri April 07, 2023 08:34 AM
From: Sergey Tulyakov
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Original Message:
Sent: 4/7/2023 8:28:00 AM
From: SANGAMESH MALLAYYA
Subject: RE: Recent DNF and YUM issues with newer python3 and curl builds

Hi Sergey,

It will be with python3.9 for DNF and other toolbox packages.

We are waiting for an approval before we start uploading python3.9 packages.

------------------------------
SANGAMESH

Original Message:
Sent: Thu April 06, 2023 01:42 PM
From: Sergey Tulyakov
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Sangamesh,

does 
"in a month" mean DNF will be still be 3.7-based, just  linked w/o rtl or will it be python3.9 based?
We don't  have a problem with current linkage,  but we do have a huge one with python3.7,
community support for which expires in 2 months, 3 weeks.

We aren't allowed to use expired pythons here.

Thought you said "end of March" tentatively for python3 == python3.9,  but I'm not sure.

So what are you DNF with python3.9 plans?

Thanks,

Sergey Tulyakov,
Sr SRE,  Verisign 

------------------------------
Sergey Tulyakov

Original Message:
Sent: Fri March 24, 2023 08:35 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Hi Saurabh

We are doing the testing and hopefully we will be able to have all update packages available in a month.

------------------------------
SANGAMESH

Original Message:
Sent: Thu March 23, 2023 11:00 AM
From: Saurabh Johri
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Hi Sangamesh,

Any update on permanent solution of this issue. 

------------------------------
Saurabh Johri

Original Message:
Sent: Thu December 22, 2022 06:06 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

------------------------------
SANGAMESH
------------------------------

Yes. Toolbox python3 ecosystem will be published with python3.9.

------------------------------
SANGAMESH
------------------------------

Original Message:
Sent: Fri April 07, 2023 10:05 AM
From: Sergey Tulyakov
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Original Message:
Sent: 4/7/2023 10:00:00 AM
From: SANGAMESH MALLAYYA
Subject: RE: Recent DNF and YUM issues with newer python3 and curl builds

We are hoping to have everything sorted in 1 to 1.5 months. 

------------------------------
SANGAMESH

Original Message:
Sent: Fri April 07, 2023 08:34 AM
From: Sergey Tulyakov
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Original Message:
Sent: 4/7/2023 8:28:00 AM
From: SANGAMESH MALLAYYA
Subject: RE: Recent DNF and YUM issues with newer python3 and curl builds

Hi Sergey,

It will be with python3.9 for DNF and other toolbox packages.

We are waiting for an approval before we start uploading python3.9 packages.

------------------------------
SANGAMESH

Original Message:
Sent: Thu April 06, 2023 01:42 PM
From: Sergey Tulyakov
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Sangamesh,

does 
"in a month" mean DNF will be still be 3.7-based, just  linked w/o rtl or will it be python3.9 based?
We don't  have a problem with current linkage,  but we do have a huge one with python3.7,
community support for which expires in 2 months, 3 weeks.

We aren't allowed to use expired pythons here.

Thought you said "end of March" tentatively for python3 == python3.9,  but I'm not sure.

So what are you DNF with python3.9 plans?

Thanks,

Sergey Tulyakov,
Sr SRE,  Verisign 

------------------------------
Sergey Tulyakov

Original Message:
Sent: Fri March 24, 2023 08:35 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Hi Saurabh

We are doing the testing and hopefully we will be able to have all update packages available in a month.

------------------------------
SANGAMESH

Original Message:
Sent: Thu March 23, 2023 11:00 AM
From: Saurabh Johri
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Hi Sangamesh,

Any update on permanent solution of this issue. 

------------------------------
Saurabh Johri

Original Message:
Sent: Thu December 22, 2022 06:06 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

------------------------------
SANGAMESH
------------------------------

Hi Sergey,

It will be with python3.9 for DNF and other toolbox packages.

We are waiting for an approval before we start uploading python3.9 packages.

------------------------------
SANGAMESH

Original Message:
Sent: Thu April 06, 2023 01:42 PM
From: Sergey Tulyakov
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Sangamesh,

does 
"in a month" mean DNF will be still be 3.7-based, just  linked w/o rtl or will it be python3.9 based?
We don't  have a problem with current linkage,  but we do have a huge one with python3.7,
community support for which expires in 2 months, 3 weeks.

We aren't allowed to use expired pythons here.

Thought you said "end of March" tentatively for python3 == python3.9,  but I'm not sure.

So what are you DNF with python3.9 plans?

Thanks,

Sergey Tulyakov,
Sr SRE,  Verisign 

------------------------------
Sergey Tulyakov

Original Message:
Sent: Fri March 24, 2023 08:35 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Hi Saurabh

We are doing the testing and hopefully we will be able to have all update packages available in a month.

------------------------------
SANGAMESH

Original Message:
Sent: Thu March 23, 2023 11:00 AM
From: Saurabh Johri
Subject: Recent DNF and YUM issues with newer python3 and curl builds

Hi Sangamesh,

Any update on permanent solution of this issue. 

------------------------------
Saurabh Johri

Original Message:
Sent: Thu December 22, 2022 06:06 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

------------------------------
SANGAMESH
------------------------------

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

------------------------------
SANGAMESH
------------------------------

Fresh AIX 7300 install patched to 7300-01-01-2246.
downloaded the openssh v8 and oenssl v3 from that other IBM website I found listed in another post here.
installed both LPP packages

ran the DNF install script from https://public.dhe.ibm.com/aix/freeSoftware/aixtoolbox/ezinstall/ppc/dnf_aixtoolbox.sh
after download and install (no errors) 

Ran updtvpkg

I try to dnf -y update

# /opt/freeware/bin/dnf -y update
Last metadata expiration check: 0:03:23 ago on Wed Mar 29 15:17:54 EDT 2023.
Error:
 Problem: cannot install the best update candidate for package tk-8.4.7-3.ppc
  - nothing provides libX11.a(shr4.o) needed by tk-8.6.11-1.ppc
  - nothing provides libX11.a(shr_64.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr_64.o) needed by tk-8.6.11-1.ppc
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

This is a headless system.
What is the solution/work around or do I have to wait for fix?

------------------------------
Demian Phillips

Original Message:
Sent: Thu December 22, 2022 06:06 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

------------------------------
SANGAMESH
------------------------------

Hello Demian,

did you check your configured repositories? It might be, that you still have a repo for AIX 7.2 instead of AIX 7.3.

best regards

Fresh AIX 7300 install patched to 7300-01-01-2246.
downloaded the openssh v8 and oenssl v3 from that other IBM website I found listed in another post here.
installed both LPP packages

ran the DNF install script from https://public.dhe.ibm.com/aix/freeSoftware/aixtoolbox/ezinstall/ppc/dnf_aixtoolbox.sh
after download and install (no errors) 

Ran updtvpkg

I try to dnf -y update

# /opt/freeware/bin/dnf -y update
Last metadata expiration check: 0:03:23 ago on Wed Mar 29 15:17:54 EDT 2023.
Error:
 Problem: cannot install the best update candidate for package tk-8.4.7-3.ppc
  - nothing provides libX11.a(shr4.o) needed by tk-8.6.11-1.ppc
  - nothing provides libX11.a(shr_64.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr_64.o) needed by tk-8.6.11-1.ppc
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

This is a headless system.
What is the solution/work around or do I have to wait for fix?

------------------------------
Demian Phillips

Original Message:
Sent: Thu December 22, 2022 06:06 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

------------------------------
SANGAMESH
------------------------------

Not sure why I would be pointed to 7.2 on a fresh 7.3 install.

# /opt/freeware/bin/dnf repolist
repo id                             repo name
AIX_Toolbox                         AIX generic repository
AIX_Toolbox_73                      AIX 7.3 specific repository
AIX_Toolbox_noarch                  AIX noarch repository

No looks good.
Thanks for the suggestion though.

Hello Demian,

did you check your configured repositories? It might be, that you still have a repo for AIX 7.2 instead of AIX 7.3.

best regards

Fresh AIX 7300 install patched to 7300-01-01-2246.
downloaded the openssh v8 and oenssl v3 from that other IBM website I found listed in another post here.
installed both LPP packages

ran the DNF install script from https://public.dhe.ibm.com/aix/freeSoftware/aixtoolbox/ezinstall/ppc/dnf_aixtoolbox.sh
after download and install (no errors) 

Ran updtvpkg

I try to dnf -y update

# /opt/freeware/bin/dnf -y update
Last metadata expiration check: 0:03:23 ago on Wed Mar 29 15:17:54 EDT 2023.
Error:
 Problem: cannot install the best update candidate for package tk-8.4.7-3.ppc
  - nothing provides libX11.a(shr4.o) needed by tk-8.6.11-1.ppc
  - nothing provides libX11.a(shr_64.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr_64.o) needed by tk-8.6.11-1.ppc
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

This is a headless system.
What is the solution/work around or do I have to wait for fix?

------------------------------
Demian Phillips

Original Message:
Sent: Thu December 22, 2022 06:06 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

------------------------------
SANGAMESH
------------------------------

the two missing files are part of aix X11.base.lib fileset, guess this lpp is not installed on your lpar

root@nimvie: /usr/lib # lslpp -w /usr/lib/libX11.a  File                                        Fileset               Type  ----------------------------------------------------------------------------  /usr/lib/libX11.a                           X11.base.lib          Symlinkroot@nimvie: /usr/lib # lslpp -w /usr/lib/libXext.a  File                                        Fileset               Type  ----------------------------------------------------------------------------  /usr/lib/libXext.a                          X11.base.lib          Symlink

Not sure why I would be pointed to 7.2 on a fresh 7.3 install.

# /opt/freeware/bin/dnf repolist
repo id                             repo name
AIX_Toolbox                         AIX generic repository
AIX_Toolbox_73                      AIX 7.3 specific repository
AIX_Toolbox_noarch                  AIX noarch repository

No looks good.
Thanks for the suggestion though.

Hello Demian,

did you check your configured repositories? It might be, that you still have a repo for AIX 7.2 instead of AIX 7.3.

best regards

Fresh AIX 7300 install patched to 7300-01-01-2246.
downloaded the openssh v8 and oenssl v3 from that other IBM website I found listed in another post here.
installed both LPP packages

ran the DNF install script from https://public.dhe.ibm.com/aix/freeSoftware/aixtoolbox/ezinstall/ppc/dnf_aixtoolbox.sh
after download and install (no errors) 

Ran updtvpkg

I try to dnf -y update

# /opt/freeware/bin/dnf -y update
Last metadata expiration check: 0:03:23 ago on Wed Mar 29 15:17:54 EDT 2023.
Error:
 Problem: cannot install the best update candidate for package tk-8.4.7-3.ppc
  - nothing provides libX11.a(shr4.o) needed by tk-8.6.11-1.ppc
  - nothing provides libX11.a(shr_64.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr_64.o) needed by tk-8.6.11-1.ppc
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

This is a headless system.
What is the solution/work around or do I have to wait for fix?

------------------------------
Demian Phillips

Original Message:
Sent: Thu December 22, 2022 06:06 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

------------------------------
SANGAMESH
------------------------------

I do not understand why I need to install X11 on a headless system just so DNF can update it's basic packages.

the two missing files are part of aix X11.base.lib fileset, guess this lpp is not installed on your lpar

root@nimvie: /usr/lib # lslpp -w /usr/lib/libX11.a  File                                        Fileset               Type  ----------------------------------------------------------------------------  /usr/lib/libX11.a                           X11.base.lib          Symlinkroot@nimvie: /usr/lib # lslpp -w /usr/lib/libXext.a  File                                        Fileset               Type  ----------------------------------------------------------------------------  /usr/lib/libXext.a                          X11.base.lib          Symlink

Not sure why I would be pointed to 7.2 on a fresh 7.3 install.

# /opt/freeware/bin/dnf repolist
repo id                             repo name
AIX_Toolbox                         AIX generic repository
AIX_Toolbox_73                      AIX 7.3 specific repository
AIX_Toolbox_noarch                  AIX noarch repository

No looks good.
Thanks for the suggestion though.

Hello Demian,

did you check your configured repositories? It might be, that you still have a repo for AIX 7.2 instead of AIX 7.3.

best regards

Fresh AIX 7300 install patched to 7300-01-01-2246.
downloaded the openssh v8 and oenssl v3 from that other IBM website I found listed in another post here.
installed both LPP packages

ran the DNF install script from https://public.dhe.ibm.com/aix/freeSoftware/aixtoolbox/ezinstall/ppc/dnf_aixtoolbox.sh
after download and install (no errors) 

Ran updtvpkg

I try to dnf -y update

# /opt/freeware/bin/dnf -y update
Last metadata expiration check: 0:03:23 ago on Wed Mar 29 15:17:54 EDT 2023.
Error:
 Problem: cannot install the best update candidate for package tk-8.4.7-3.ppc
  - nothing provides libX11.a(shr4.o) needed by tk-8.6.11-1.ppc
  - nothing provides libX11.a(shr_64.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr_64.o) needed by tk-8.6.11-1.ppc
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

This is a headless system.
What is the solution/work around or do I have to wait for fix?

------------------------------
Demian Phillips

Original Message:
Sent: Thu December 22, 2022 06:06 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

------------------------------
SANGAMESH
------------------------------

I do not understand why I need to install X11 on a headless system just so DNF can update it's basic packages.

the two missing files are part of aix X11.base.lib fileset, guess this lpp is not installed on your lpar

root@nimvie: /usr/lib # lslpp -w /usr/lib/libX11.a  File                                        Fileset               Type  ----------------------------------------------------------------------------  /usr/lib/libX11.a                           X11.base.lib          Symlinkroot@nimvie: /usr/lib # lslpp -w /usr/lib/libXext.a  File                                        Fileset               Type  ----------------------------------------------------------------------------  /usr/lib/libXext.a                          X11.base.lib          Symlink

Not sure why I would be pointed to 7.2 on a fresh 7.3 install.

# /opt/freeware/bin/dnf repolist
repo id                             repo name
AIX_Toolbox                         AIX generic repository
AIX_Toolbox_73                      AIX 7.3 specific repository
AIX_Toolbox_noarch                  AIX noarch repository

No looks good.
Thanks for the suggestion though.

Hello Demian,

did you check your configured repositories? It might be, that you still have a repo for AIX 7.2 instead of AIX 7.3.

best regards

Fresh AIX 7300 install patched to 7300-01-01-2246.
downloaded the openssh v8 and oenssl v3 from that other IBM website I found listed in another post here.
installed both LPP packages

ran the DNF install script from https://public.dhe.ibm.com/aix/freeSoftware/aixtoolbox/ezinstall/ppc/dnf_aixtoolbox.sh
after download and install (no errors) 

Ran updtvpkg

I try to dnf -y update

# /opt/freeware/bin/dnf -y update
Last metadata expiration check: 0:03:23 ago on Wed Mar 29 15:17:54 EDT 2023.
Error:
 Problem: cannot install the best update candidate for package tk-8.4.7-3.ppc
  - nothing provides libX11.a(shr4.o) needed by tk-8.6.11-1.ppc
  - nothing provides libX11.a(shr_64.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr_64.o) needed by tk-8.6.11-1.ppc
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

This is a headless system.
What is the solution/work around or do I have to wait for fix?

------------------------------
Demian Phillips

Original Message:
Sent: Thu December 22, 2022 06:06 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

------------------------------
SANGAMESH
------------------------------

dnf said it needed to update 'tk', and 'tk' is tcl's GUI api, so it needs X11, so I guess that the previous tk wasn't packed with the X11 dependency (which is wrong), and the current tk is (which is right).

Any reason to install tk if you're not using graphical applications ? (Usually it's some application that packs the CLI and GUI in a single rpm)

I do not understand why I need to install X11 on a headless system just so DNF can update it's basic packages.

the two missing files are part of aix X11.base.lib fileset, guess this lpp is not installed on your lpar

root@nimvie: /usr/lib # lslpp -w /usr/lib/libX11.a  File                                        Fileset               Type  ----------------------------------------------------------------------------  /usr/lib/libX11.a                           X11.base.lib          Symlinkroot@nimvie: /usr/lib # lslpp -w /usr/lib/libXext.a  File                                        Fileset               Type  ----------------------------------------------------------------------------  /usr/lib/libXext.a                          X11.base.lib          Symlink

Not sure why I would be pointed to 7.2 on a fresh 7.3 install.

# /opt/freeware/bin/dnf repolist
repo id                             repo name
AIX_Toolbox                         AIX generic repository
AIX_Toolbox_73                      AIX 7.3 specific repository
AIX_Toolbox_noarch                  AIX noarch repository

No looks good.
Thanks for the suggestion though.

Hello Demian,

did you check your configured repositories? It might be, that you still have a repo for AIX 7.2 instead of AIX 7.3.

best regards

Fresh AIX 7300 install patched to 7300-01-01-2246.
downloaded the openssh v8 and oenssl v3 from that other IBM website I found listed in another post here.
installed both LPP packages

ran the DNF install script from https://public.dhe.ibm.com/aix/freeSoftware/aixtoolbox/ezinstall/ppc/dnf_aixtoolbox.sh
after download and install (no errors) 

Ran updtvpkg

I try to dnf -y update

# /opt/freeware/bin/dnf -y update
Last metadata expiration check: 0:03:23 ago on Wed Mar 29 15:17:54 EDT 2023.
Error:
 Problem: cannot install the best update candidate for package tk-8.4.7-3.ppc
  - nothing provides libX11.a(shr4.o) needed by tk-8.6.11-1.ppc
  - nothing provides libX11.a(shr_64.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr_64.o) needed by tk-8.6.11-1.ppc
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

This is a headless system.
What is the solution/work around or do I have to wait for fix?

------------------------------
Demian Phillips

Original Message:
Sent: Thu December 22, 2022 06:06 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

------------------------------
SANGAMESH
------------------------------

dnf said it needed to update 'tk', and 'tk' is tcl's GUI api, so it needs X11, so I guess that the previous tk wasn't packed with the X11 dependency (which is wrong), and the current tk is (which is right).

Any reason to install tk if you're not using graphical applications ? (Usually it's some application that packs the CLI and GUI in a single rpm)

I do not understand why I need to install X11 on a headless system just so DNF can update it's basic packages.

the two missing files are part of aix X11.base.lib fileset, guess this lpp is not installed on your lpar

root@nimvie: /usr/lib # lslpp -w /usr/lib/libX11.a  File                                        Fileset               Type  ----------------------------------------------------------------------------  /usr/lib/libX11.a                           X11.base.lib          Symlinkroot@nimvie: /usr/lib # lslpp -w /usr/lib/libXext.a  File                                        Fileset               Type  ----------------------------------------------------------------------------  /usr/lib/libXext.a                          X11.base.lib          Symlink

Not sure why I would be pointed to 7.2 on a fresh 7.3 install.

# /opt/freeware/bin/dnf repolist
repo id                             repo name
AIX_Toolbox                         AIX generic repository
AIX_Toolbox_73                      AIX 7.3 specific repository
AIX_Toolbox_noarch                  AIX noarch repository

No looks good.
Thanks for the suggestion though.

Hello Demian,

did you check your configured repositories? It might be, that you still have a repo for AIX 7.2 instead of AIX 7.3.

best regards

Fresh AIX 7300 install patched to 7300-01-01-2246.
downloaded the openssh v8 and oenssl v3 from that other IBM website I found listed in another post here.
installed both LPP packages

ran the DNF install script from https://public.dhe.ibm.com/aix/freeSoftware/aixtoolbox/ezinstall/ppc/dnf_aixtoolbox.sh
after download and install (no errors) 

Ran updtvpkg

I try to dnf -y update

# /opt/freeware/bin/dnf -y update
Last metadata expiration check: 0:03:23 ago on Wed Mar 29 15:17:54 EDT 2023.
Error:
 Problem: cannot install the best update candidate for package tk-8.4.7-3.ppc
  - nothing provides libX11.a(shr4.o) needed by tk-8.6.11-1.ppc
  - nothing provides libX11.a(shr_64.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr_64.o) needed by tk-8.6.11-1.ppc
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

This is a headless system.
What is the solution/work around or do I have to wait for fix?

------------------------------
Demian Phillips

Original Message:
Sent: Thu December 22, 2022 06:06 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

------------------------------
SANGAMESH
------------------------------

Didnt install it or anything that should have required it.

I installed fresh AIX 7.3 on headless physical server in datacenter.

Set up NIM server in preparation for deploying systems in datacenter.

Needed unzip so I could uncompress some IBM downloads for above NIM setup and HMC updates.

Ran DNF setup per https://www.ibm.com/support/pages/aix-toolbox-open-source-software-get-started

used the script provided at above website.

After DNF installed (used the -d option) it said to update dnf

Thats where the errors started.

dnf said it needed to update 'tk', and 'tk' is tcl's GUI api, so it needs X11, so I guess that the previous tk wasn't packed with the X11 dependency (which is wrong), and the current tk is (which is right).

Any reason to install tk if you're not using graphical applications ? (Usually it's some application that packs the CLI and GUI in a single rpm)

I do not understand why I need to install X11 on a headless system just so DNF can update it's basic packages.

the two missing files are part of aix X11.base.lib fileset, guess this lpp is not installed on your lpar

root@nimvie: /usr/lib # lslpp -w /usr/lib/libX11.a  File                                        Fileset               Type  ----------------------------------------------------------------------------  /usr/lib/libX11.a                           X11.base.lib          Symlinkroot@nimvie: /usr/lib # lslpp -w /usr/lib/libXext.a  File                                        Fileset               Type  ----------------------------------------------------------------------------  /usr/lib/libXext.a                          X11.base.lib          Symlink

Not sure why I would be pointed to 7.2 on a fresh 7.3 install.

# /opt/freeware/bin/dnf repolist
repo id                             repo name
AIX_Toolbox                         AIX generic repository
AIX_Toolbox_73                      AIX 7.3 specific repository
AIX_Toolbox_noarch                  AIX noarch repository

No looks good.
Thanks for the suggestion though.

Hello Demian,

did you check your configured repositories? It might be, that you still have a repo for AIX 7.2 instead of AIX 7.3.

best regards

Fresh AIX 7300 install patched to 7300-01-01-2246.
downloaded the openssh v8 and oenssl v3 from that other IBM website I found listed in another post here.
installed both LPP packages

ran the DNF install script from https://public.dhe.ibm.com/aix/freeSoftware/aixtoolbox/ezinstall/ppc/dnf_aixtoolbox.sh
after download and install (no errors) 

Ran updtvpkg

I try to dnf -y update

# /opt/freeware/bin/dnf -y update
Last metadata expiration check: 0:03:23 ago on Wed Mar 29 15:17:54 EDT 2023.
Error:
 Problem: cannot install the best update candidate for package tk-8.4.7-3.ppc
  - nothing provides libX11.a(shr4.o) needed by tk-8.6.11-1.ppc
  - nothing provides libX11.a(shr_64.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr_64.o) needed by tk-8.6.11-1.ppc
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

This is a headless system.
What is the solution/work around or do I have to wait for fix?

------------------------------
Demian Phillips

Original Message:
Sent: Thu December 22, 2022 06:06 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

------------------------------
SANGAMESH
------------------------------

Hello Demian,

did you check your configured repositories? It might be, that you still have a repo for AIX 7.2 instead of AIX 7.3.

best regards

Fresh AIX 7300 install patched to 7300-01-01-2246.
downloaded the openssh v8 and oenssl v3 from that other IBM website I found listed in another post here.
installed both LPP packages

ran the DNF install script from https://public.dhe.ibm.com/aix/freeSoftware/aixtoolbox/ezinstall/ppc/dnf_aixtoolbox.sh
after download and install (no errors) 

Ran updtvpkg

I try to dnf -y update

# /opt/freeware/bin/dnf -y update
Last metadata expiration check: 0:03:23 ago on Wed Mar 29 15:17:54 EDT 2023.
Error:
 Problem: cannot install the best update candidate for package tk-8.4.7-3.ppc
  - nothing provides libX11.a(shr4.o) needed by tk-8.6.11-1.ppc
  - nothing provides libX11.a(shr_64.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr_64.o) needed by tk-8.6.11-1.ppc
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

This is a headless system.
What is the solution/work around or do I have to wait for fix?

------------------------------
Demian Phillips

Original Message:
Sent: Thu December 22, 2022 06:06 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

------------------------------
SANGAMESH
------------------------------

Hello Demian,

did you check your configured repositories? It might be, that you still have a repo for AIX 7.2 instead of AIX 7.3.

best regards

Fresh AIX 7300 install patched to 7300-01-01-2246.
downloaded the openssh v8 and oenssl v3 from that other IBM website I found listed in another post here.
installed both LPP packages

ran the DNF install script from https://public.dhe.ibm.com/aix/freeSoftware/aixtoolbox/ezinstall/ppc/dnf_aixtoolbox.sh
after download and install (no errors) 

Ran updtvpkg

I try to dnf -y update

# /opt/freeware/bin/dnf -y update
Last metadata expiration check: 0:03:23 ago on Wed Mar 29 15:17:54 EDT 2023.
Error:
 Problem: cannot install the best update candidate for package tk-8.4.7-3.ppc
  - nothing provides libX11.a(shr4.o) needed by tk-8.6.11-1.ppc
  - nothing provides libX11.a(shr_64.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr.o) needed by tk-8.6.11-1.ppc
  - nothing provides libXext.a(shr_64.o) needed by tk-8.6.11-1.ppc
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

This is a headless system.
What is the solution/work around or do I have to wait for fix?

------------------------------
Demian Phillips

Original Message:
Sent: Thu December 22, 2022 06:06 AM
From: SANGAMESH MALLAYYA
Subject: Recent DNF and YUM issues with newer python3 and curl builds

What's the issue

AIX Toolbox users who are using YUM or DNF would have experienced issues recently.

1. With "yum update" update fails with Requires: (libcomps >= 0.1.11-101 if dnf).

yum update fails with an error Requires: (libcomps >= 0.1.11-101 if dnf)

2. With "dnf update" it exits with illegal instruction while installing specific packages like sudo, GeoIP-devel-1.6.12-1.ppc etc.

How it started

 Let us  give little background on how these issue started.

We have started building toolbox packages with openssl-1.1.1, as there was a need to move to openssl-1.1.1 due to TLS 1.3 support
and other security features.

Since not all toolbox packages built with openssl-1.1.1, the DNF dependencies were having packages mix with both openssl-1.0.2 and 1.1.1.

Ideally, the environment mixed openssl 1.0.2 and 1.1.1 would not have any issue as the libraries should be able to resolve symbols from
the corresponding openssl dependent library.

But we have started seeing issues with DNF when only curl is built with openssl-1.1.1 but not the other DNF dependencies.
This is because of the python3 was built with runtime linking (brtl  flag) enabled.
This was causing a intermix of symbols being used from wrong openssl library.

For example. If shared library data is initialized with openssl-1.1.1 at the beginning, and then later when 1.0.2 is loaded,
the functions from 1.1.1 were calling 1.0.2 functions which returning uninitialized data.

To resolve this we decided to rebuild python3 without the runtime linking enabled.

This requires libcomps to be also rebuilt for dnf to work. Since libcomps is not a dependency for python3,
we had to put a conditional requires "libcomps >= 0.1.11-101 if dnf" on python3 and also on curl "python3 >= 3.7.15-1 if dnf"
to make sure all these three packages will be in sync during dnf update.

This resolved the main issue but exposed another issue with rpm module and dnf started failing with IIlegal Instruction error.
And since yum parser is too old to understand this conditional requires statement, YUM is also broken.

How to resolve the existing DNF or YUM issues

We have rebuilt python3 with runtime linking (brtl) again and all DNF dependencies with openssl-1.1.1 to have only
openssl-1.1.1 library to be used throughout the DNF session.

To make YUM also work, we have rebuilt python2 & python-pycurl with openssl 1.1.1.

The conditional requires statement is also removed now which means the users have to do "dnf update" or "yum update"
to make all packages in sync, rather than updating individually (like "dnf update curl")

With this users currently won't face DNF core dump and YUM update issue.

So, we recommend the users to do the "dnf update" or "yum update" to get their current failing environment to working condition.

Plan going forward

The current solution to resolve existing DNF or YUM issues is temporary to not to break the existing working environment.

The ideal and permanent solution is to build python3 and other packages without runtime linking.

Mostly by end of 1Q 2023 we would have the DNF environment built without runtime linking (brtl flag).

Our recommendation

Please run "dnf update" or "yum update" instead of installing/updating individual packages, as the latter will not bring all the
packages built with openssl-1.1.1 required for DNF or YUM to function correctly.

It is recommended to move to DNF completely from YUM as we won't be supporting YUM anymore and any issues with YUM won't be worked on.

------------------------------
SANGAMESH
------------------------------