On Wed, Apr 12, 2017 at 8:58 AM, jan matejek wrote:

On 10.4.2017 17:25, Todd Rme wrote:

...

In devel:languages:python, the new singlespec approach is causing problems with SLE_12_SP2_Backports build target. The issue is that this build target fails if a package includes files from any package in SLE, and packages that have this problem include some really critical ones like setuptools.

This is a problem because in most cases only the python2 versions of the files are available from SLE, but the build failure means the python3 versions do not get published. This results in critical python3 packages needed for singlespec builds not being available. Currently more than half of the packages are either disabled or unresolvable, and that number is going to grow to almost every package as the singlespec conversion continues.

Does it mean that we are not allowed to use "python2-setuptools" from local repository because "python-setuptools" is part of SLE and should be used in the SLE version? Or does the build of "python2-setuptools" fail because the resulting RPM has file conflicts with a package present in SLE?

The latter. It checks individual files and if those files are already in SLE, it will fail.

In any case, I'm confused as to what is the purpose of the Backports repository. Are people expected to add it straight from OBS and install OBS-built RPMs?

It is described here: https://en.opensuse.org/Portal:Backports Basically, the idea seems to be to guarantee that no potentially incompatible updates of files in SLE get included. So you can be 100% sure that these are only add-ons with nothing that could interfere with the tested, support SLE packages.

What if the SLE version is too old, or the d:l:py version is too new?

Then we would probably need to manually disable that package.

Would only building "python3-foo" help at all?

For most critical packages that should solve the problem.

...

The simplest solution would be to just disable that repo by default. However, if there (or could be) some way to selectively disable building python2 versions of specific packages just for that build target it might be better.

We could also create a custom version of python-rpm-macros that contains the "python2 blacklist" as part of itself. As long as it is limited to d:l:py(SLE12_Backports), this might very well be the cleanest solution -- no need to touch individual specs.

That is a good idea. Maybe we could create link called "python-rpm-macros_SLE12_Backports" that includes a package diff that adds the blacklist? Then we could disable python-rpm-macros on SLE12_Backports and enable python-rpm-macros_SLE12_Backports only for SLE12_Backports. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Wed, 2017-04-12 at 10:14 -0400, Todd Rme wrote:

On Wed, Apr 12, 2017 at 8:58 AM, jan matejek wrote:

...

On 10.4.2017 17:25, Todd Rme wrote:

...

In devel:languages:python, the new singlespec approach is causing problems with SLE_12_SP2_Backports build target. The issue is that this build target fails if a package includes files from any package in SLE, and packages that have this problem include some really critical ones like setuptools.

This is a problem because in most cases only the python2 versions of the files are available from SLE, but the build failure means the python3 versions do not get published. This results in critical python3 packages needed for singlespec builds not being available. Currently more than half of the packages are either disabled or unresolvable, and that number is going to grow to almost every package as the singlespec conversion continues.

Does it mean that we are not allowed to use "python2-setuptools" from local repository because "python-setuptools" is part of SLE and should be used in the SLE version? Or does the build of "python2-setuptools" fail because the resulting RPM has file conflicts with a package present in SLE?

The latter. It checks individual files and if those files are already in SLE, it will fail.

...

In any case, I'm confused as to what is the purpose of the Backports repository. Are people expected to add it straight from OBS and install OBS-built RPMs?

It is described here: https://en.opensuse.org/Portal:Backports

Basically, the idea seems to be to guarantee that no potentially incompatible updates of files in SLE get included. So you can be 100% sure that these are only add-ons with nothing that could interfere with the tested, support SLE packages.

...

What if the SLE version is too old, or the d:l:py version is too new?

Then we would probably need to manually disable that package.

...

Would only building "python3-foo" help at all?

For most critical packages that should solve the problem.

...

...

The simplest solution would be to just disable that repo by default. However, if there (or could be) some way to selectively disable building python2 versions of specific packages just for that build target it might be better.

We could also create a custom version of python-rpm-macros that contains the "python2 blacklist" as part of itself. As long as it is limited to d:l:py(SLE12_Backports), this might very well be the cleanest solution -- no need to touch individual specs.

That is a good idea. Maybe we could create link called "python-rpm-macros_SLE12_Backports" that includes a package diff that adds the blacklist? Then we could disable python-rpm-macros on SLE12_Backports and enable python-rpm-macros_SLE12_Backports only for SLE12_Backports.

What was the outcome of this? Is there something we can do within the Backports projects to fix the issue? Currently the multi version build is blocking us from submitting packages that require the python3 packages, but we conflict with the python2 versions in SLE. -Scott

On Wed, 2017-07-05 at 13:53 +0200, Christian wrote:

Am 05.07.2017 um 12:31 schrieb Scott Bahling:

...

Currently the multi version build is blocking us from submitting packages that require the python3 packages, but we conflict with the python2 versions in SLE.

which also prevent obviously us from having certbot/fail2ban in Backports. I would really appreciate having this prob fixed and see certbot/fail2ban ...

Yep! I was just looking into fail2ban based on your other request which triggered my question here. -Scott