- openSUSE Python - openSUSE Mailing Lists

Improvements for ansiblegate module coming

by Jochen Breuer

Hello everybody, in a few moments there will be an SR to Factory with some improvements for the ansiblegate module coming: # PATCH-FIX_UPSTREAM: https://github.com/saltstack/salt/pull/60056 Patch168: improvements-on-ansiblegate-module-354.patch As always you can add the repo with this command on Tumbleweed: `zypper ar https://download.opensuse.org/repositories/systemsmanagement:/saltstack:/te… salt-testing`. Please let us know if you run into any problems or if you've got questions. Thanks a lot! Jochen

3 weeks, 4 days

1
0
0 0

6 new patches coming to Salt in Factory

by Jochen Breuer

Hello everybody, in a few minutes we'll have six new patches coming to systemsmanagement:saltstack/salt and Factory – and therefore also soon to Tumbleweed: # PATCH-FIX_OPENSUSE: https://github.com/openSUSE/salt/pull/313 Patch162: allow-vendor-change-option-with-zypper-313.patch # PATCH-FIX_UPSTREAM: https://github.com/saltstack/salt/pull/59404 # PATCH-FIX_OPENSUSE: https://github.com/openSUSE/salt/pull/341 Patch163: add-almalinux-and-alibaba-cloud-linux-to-the-os-fami.patch # PATCH-FIX_OPENSUSE: https://github.com/openSUSE/salt/pull/347 Patch164: notify-beacon-for-debian-ubuntu-systems-347.patch # PATCH-FIX_OPENSUSE: https://github.com/openSUSE/salt/pull/336 Patch165: update-target-fix-for-salt-ssh-to-process-targets-li.patch # PATCH-FIX_UPSTREAM: https://github.com/saltstack/salt/pull/59687 Patch166: add-alibaba-cloud-linux-2-by-backporting-upstream-s-.patch # PATCH-FIX_OPENSUSE: https://github.com/openSUSE/salt/pull/353 Patch167: regression-fix-of-salt-ssh-on-processing-targets-353.patch As always you can add the repo with this command: `zypper ar https://download.opensuse.org/repositories/systemsmanagement:/saltstack:/te… salt-testing`. Please let us know if you run into any problems or if you've got questions. Thanks a lot! Jochen

1 month

1
0
0 0

build error question

by Arun Persaud

Hi I'm trying to update python-distribution in dlp:numerics https://build.opensuse.org/package/show/home:apersaud:branches:devel:langua… and I'm getting some build failures. It seems that some macros expand $name somewhere and therefore it is looking for python38-python-distributed instead of just python38-distributed. It builds OK for 586 though?! I cannot figure out if there is something wrong with the spec file or if its a macro definition... does anyone have any ideas on how to fix this? Thanks Arun

1 month, 1 week

2
2
0 0

4 patches for Salt

by Jochen Breuer

Hello everybody, we've got four new patches coming to Salt in Factory and therefore also soon Tumbleweed: # PATCH-FIX_UPSTREAM: https://github.com/saltstack/salt/pull/59524 Patch158: prevent-race-condition-on-sigterm-for-the-minion-bsc.patch # PATCH-FIX_UPSTREAM: https://github.com/saltstack/salt/pull/59746 Patch159: do-not-monkey-patch-yaml-bsc-1177474.patch # PATCH-FIX_UPSTREAM: https://github.com/saltstack/salt/pull/59536 Patch160: 3002-set-distro-requirement-to-oldest-supported-vers.patch # PATCH-FIX_UPSTREAM: https://github.com/saltstack/salt/pull/59693 Patch161: virt.network_update-handle-missing-ipv4-netmask-attr.patch Patch159 is fixing an incompatibility issue with the community.general.saltstack plugin from Ansible that exists up until version 2.9 of Ansible. As always you can add the repo with this command: `zypper ar https://download.opensuse.org/repositories/systemsmanagement:/saltstack:/te… salt-testing`. Please let us know if you run into any problems or if you've got questions. Thanks a lot! Jochen

2 months

1
0
0 0

Several CVE fixes for Salt coming

by Jochen Breuer

Hello everybody, as you can see, we had quite a list of CVE fixes coming to Salt. Changes are coming to systemsmanagement:saltstack/salt and Factory very soon. Here are the changes: - Allow extra_filerefs as sanitized kwargs for SSH client - Fix regression on cmd.run when passing tuples as cmd (bsc#1182740) - Fix for multiple for security issues (CVE-2020-28243) (CVE-2020-28972) (CVE-2020-35662) (CVE-2021-3148) (CVE-2021-3144) (CVE-2021-25281) (CVE-2021-25282) (CVE-2021-25283) (CVE-2021-25284) (CVE-2021-3197) (bsc#1181550) (bsc#1181556) (bsc#1181557) (bsc#1181558) (bsc#1181559) (bsc#1181560) (bsc#1181561) (bsc#1181562) (bsc#1181563) (bsc#1181564) (bsc#1181565) - Implementation of suse_ip execution module to prevent issues with network.managed (bsc#1099976) - Add sleep on exception handling on minion connection attempt to the master (bsc#1174855) - Allows for the VMware provider to handle CPU and memory hot-add in newer versions of the software. (bsc#1181347) - Always require python-certifi (used by salt.ext.tornado) - Bring missing part of async batch implementation back (bsc#1182382) (CVE-2021-25315) As always you can add the repo with this command: `zypper ar https://download.opensuse.org/repositories/systemsmanagement:/saltstack:/te… salt-testing`. Please let us know if you run into any problems or if you've got questions. Thanks a lot! Jochen

2 months, 2 weeks

1
0
0 0

New patches for Salt on their way to Factory

by Jochen Breuer

Hello everybody, there are five new patches for Salt coming to Factory very soon: +# PATCH-FIX_UPSTREAM: https://github.com/saltstack/salt/pull/59345 +Patch146: fix-onlyif-unless-when-multiple-conditions-bsc-11808.patch +# PATCH-FIX_UPSTREAM: https://github.com/saltstack/salt/pull/59354 +Patch147: do-not-crash-when-unexpected-cmd-output-at-listing-p.patch +# PATCH-FIX_UPSTREAM: https://github.com/saltstack/salt/pull/59189 +Patch148: virt-uefi-fix-backport-312.patch +# PATCH-FIX_UPSTREAM: https://github.com/saltstack/salt/pull/59355 +# https://github.com/saltstack/salt/pull/59417 +Patch149: 3002.2-xen-spicevmc-dns-srv-records-backports-314.patch +# PATCH-FIX_UPSTREAM: https://github.com/saltstack/salt/pull/59485 +Patch150: open-suse-3002.2-xen-grub-316.patch As always you can add the repo with this command: `zypper ar https://download.opensuse.org/repositories/systemsmanagement:/saltstack:/te… salt-testing`. Please let us know if you run into any problems or if you've got questions. Thanks a lot! Jochen

3 months

1
0
0 0

Python 3 parallel install (Re: Tumbleweed - Review of the week 2020/52)

by Ben Greiner

Hello, my apologies in advance if this mail reaches you up to three times, but in my opinion the topic is relevant and important to reach people subscribed to all three mailing lists. Am 25.12.20 um 18:34 schrieb Dominique Leuenberger / DimStar an factory(a)lists.opensuse.org: > * Multiple python 3 versions parallel installable. Adding to python > 3.8, version 3.6 will be reintroduced. Python modules will be built > for both versions. This line sounds rather innocent, but it has severe implications: Every package python-foo, which uses the so called singlespec macro %python_subpackages, will also try to build a python36-foo package. The whole build process will fail if a step in that particular flavor fails or if building for more than one flavor will create conflicts. We took care [1] of all the packages in Ring0 and Ring1, which popped up as problematic in the staging project. But there are many more packages, which will see the change the first time, when the staging project will be accepted into Factory. You can refer to the documented changes in [1] for examples how to fix a package. There are also some updates to the wiki [2] and the documentation of python-rpm-macros [3]. In particular, look out for: - Packages already skipping Python 2 will start to produce more than one package. Avoid duplicate files by using update-alternatives (there are macros for it in python-rpm-macros), or put common files into unflavored subpackages. - If you provide or require python3-foo, it will only do that for the primary python interpreter. Replace `BuildRequires python3-foo` by `BuildRequires %{python_module foo}` and let the %python_subpackages macro do the work for all Tags and macros where it can replace the unflavored variants e.g.: * `Requires: python-bar` instead of python3-bar. * `%python_sitelib` instead of `%python3_sitelib` in `%files` - Some packages need extra packages backporting stuff to Python 3.6, e.g. importlib-metadata or dataclasses. See black as an example how to deal with this [4] - If upstream does not support python 3.6 anymore (Numpy already deprecates to support it in new releases, according to NEP 29 [5]) you can use `%define skip_python36 1`. All depending packages need to do the same. Alternatively a branched package can provide an older version for this flavor, e.g. python-ipython715 has been created to provide the last version which support Python 3.6. - Python "apps" not following the flavored python-foo naming scheme, will only collect files for one (hopefully the primary python3 providing) flavor during the packaging phase. Remove %python_modules, %python_build, %python_install, %python_expand and the sort, as it unnecessarily pulls in packages for all python flavors and tries to build and install into multiple sitelib/sitearch directories. Replace by calling python3 directly or use the equivalent %python3_* macros. - Some non-singlespec packages only create python3-foo. They will either need an update to include python36-foo, python38-foo (and python39-foo in the near future), or all depending packages must only build for the primary python3, too. `%define pythons python3` or skip all non-primary interpreters. - The previous item is also true for many packages, which have a python bindings subpackage but are not Python only. We introduced %python_subpackage_only so that these packages now can take advantage of the singlespec macros as well. The tracker comment on GitHub [6] has links to a few examples how to use it. - %ifpython3 and %python3_only are evil. They have been deprecated for some months already. Essentially, they fail to recognize the new flavors python36 and python38 which replace python3. OTOH, older distributions will continue to use the python3 flavor. We have introduced a new %python_provides macro, but did not modify %ifpython3 or %python3_only to incorporate this, because it is not automatically clear whether the conditioned code block shall apply to all flavors of Python3 packages or only to the primary interpreter. Replace by something like * `%if "%{python_flavor}" == "python3" || "%{?python_provides}" == "python3"` for sections only provided by the primary flavor. * `%if 0%{python_version_nodots} > 34` or `%if "%{python_flavor}" != "python2"` for section applicable to all Python 3 flavors. Cheers and happy coding, Ben [1] https://github.com/openSUSE/python-rpm-macros/issues/66 [2] https://en.opensuse.org/openSUSE:Packaging_Python [3] https://github.com/openSUSE/python-rpm-macros/blob/master/README.md [4] https://build.opensuse.org/request/show/853412 [5] https://numpy.org/neps/nep-0029-deprecation_policy.html [6] https://github.com/openSUSE/python-rpm-macros/issues/66#issuecomment-715538…

3 months

3
5
0 0

How to skip test in %pyunittest?

by andythe_great

Hello, I would like to know how to skip specific test in %pyunittest. For example, pytest can skip some test like this, %pytest -k 'not some_test'. but how to do it for %pyunittest? Kind regards, Andy

3 months, 3 weeks

3
2
0 0

Help needed with lots of python related build failures in openSUSE:Backports:SLE-15-SP3

by Lubos Kocman

Hello team, Leap 15.3 Beta is getting closer and closer and we're facing a lot of python build issues in Leap 15.3. *Checkin Deadline for Beta is on 12th Feb. Where to find build failures? I'm using following filter with "py" in the filter box. That gives me 95 at this very moment. https://build.opensuse.org/project/monitor/openSUSE:Backports:SLE-15-SP3?de… Could you please look at the build failures and help us to reduce the build fails? Max has reached out to me as this is currently too much for openSUSE Release Team. Just to note openSUSE:Backports is where Leap 15.3+ packages will live from now on, that's a project structure change compared to Closing the Leap Gap. *Submit requests should bedone against openSUSE:Leap:15.3, which has auto-redirect with exception of new packages. New packages unfortunatelly have to be submitted to a specific project, in Leap 15.3 case openSUSE:Backports:SLE-15-SP3 ) [0] https://en.opensuse.org/openSUSE:Roadmap [1] https://en.opensuse.org/Portal:Jump/Policy/SubmitRequests#So_where_do_I_sub… Thank you very much in advance -- Lubos Kocman Release Manager openSUSE Leap SUSE LINUX, s.r.o. Krizikova 148/34 tel: +49 173 5876850 186 00 Praha 8 http://www.suse.com Czech Republic

3 months, 3 weeks

4
4
0 0

python3-foo packages are now python36-foo and python38-packages

by Ben Greiner

Hello List subscribers, people have been complaining that they missed some important messages because the previous mails were "buried" as answers in some sub threads and understandably not everyone reads every thread due to high mail volume. So here is some more volume for you, again posting to 3 mailinglists. Top post without any reference to other mails. A major change of the python-rpm-macros and matching prjconf definitions has been introduced to Factory last Friday. Now is the time to fix your python-foo packages, or specfiles creating python3-foo subpackages. Quoting the two relevant posts below. Refer to the actual threads for discussions and comments. -------- Weitergeleitete Nachricht -------- Betreff: Re: Tumbleweed snapshot 20210115 - python can be bumpy Datum: Mon, 18 Jan 2021 13:10:21 +0100 Von: Dominique Leuenberger / DimStar <dimstar(a)opensuse.org> An: factory(a)lists.opensuse.org On Mon, 2021-01-18 at 12:00 +0000, Dominique Leuenberger wrote: > Packages changed: > python-rpm-macros (20200824.8fa42a7 -> 20210112.86f4d9d) > > === Details === > > > ==== python-rpm-macros ==== > Version update (20200824.8fa42a7 -> 20210112.86f4d9d This change has potential for quite some headaches - it was in Staging for a long time to get things sorted out 'reasonably well', BUT: depending on your python-* modules installed, this can be a rough weekfor you. There is a large number of packages that did not like the change (none of the ring packages, so 'most' users probably won't feel it) If you are a python-* maintainer and see your packages newly fail, please try to help everybody to get your packages back on track. Benjamin Greiner has proven to be very helpful in those cases. The main change is that the python-FOO spec files (when using the long established python-single-spec style, which we had already for py2/py3 in place) will produce python36-FOO and python38-FOO (the 38-FOO provides/obsoletes python3-FOO, helping for the migrationpath) The 'not too distant'; future should see this concept further enhanced with python39 added to the mix. But that is not even staged. Let's first iron out glitches with the two python3.x variants. Cheers, Dominique -------- Weitergeleitete Nachricht -------- Betreff: Python 3 parallel install (Re: Tumbleweed - Review of the week 2020/52) Datum: Sat, 26 Dec 2020 16:01:42 +0100 Von: Ben Greiner <code(a)bnavigator.de> An: factory(a)lists.opensuse.org, python(a)lists.opensuse.org, packaging(a)lists.opensuse.org Hello, my apologies in advance if this mail reaches you up to three times, but in my opinion the topic is relevant and important to reach people subscribed to all three mailing lists. Am 25.12.20 um 18:34 schrieb Dominique Leuenberger / DimStar an factory(a)lists.opensuse.org: > * Multiple python 3 versions parallel installable. Adding to python > 3.8, version 3.6 will be reintroduced. Python modules will be built > for both versions. This line sounds rather innocent, but it has severe implications: Every package python-foo, which uses the so called singlespec macro %python_subpackages, will also try to build a python36-foo package. The whole build process will fail if a step in that particular flavor fails or if building for more than one flavor will create conflicts. We took care [1] of all the packages in Ring0 and Ring1, which popped up as problematic in the staging project. But there are many more packages, which will see the change the first time, when the staging project will be accepted into Factory. You can refer to the documented changes in [1] for examples how to fix a package. There are also some updates to the wiki [2] and the documentation of python-rpm-macros [3]. In particular, look out for: - Packages already skipping Python 2 will start to produce more than one package. Avoid duplicate files by using update-alternatives (there are macros for it in python-rpm-macros), or put common files into unflavored subpackages. - If you provide or require python3-foo, it will only do that for the primary python interpreter. Replace `BuildRequires python3-foo` by `BuildRequires %{python_module foo}` and let the %python_subpackages macro do the work for all Tags and macros where it can replace the unflavored variants e.g.: * `Requires: python-bar` instead of python3-bar. * `%python_sitelib` instead of `%python3_sitelib` in `%files` - Some packages need extra packages backporting stuff to Python 3.6, e.g. importlib-metadata or dataclasses. See black as an example how to deal with this [4] - If upstream does not support python 3.6 anymore (Numpy already deprecates to support it in new releases, according to NEP 29 [5]) you can use `%define skip_python36 1`. All depending packages need to do the same. Alternatively a branched package can provide an older version for this flavor, e.g. python-ipython715 has been created to provide the last version which support Python 3.6. - Python "apps" not following the flavored python-foo naming scheme, will only collect files for one (hopefully the primary python3 providing) flavor during the packaging phase. Remove %python_modules, %python_build, %python_install, %python_expand and the sort, as it unnecessarily pulls in packages for all python flavors and tries to build and install into multiple sitelib/sitearch directories. Replace by calling python3 directly or use the equivalent %python3_* macros. - Some non-singlespec packages only create python3-foo. They will either need an update to include python36-foo, python38-foo (and python39-foo in the near future), or all depending packages must only build for the primary python3, too. `%define pythons python3` or skip all non-primary interpreters. - The previous item is also true for many packages, which have a python bindings subpackage but are not Python only. We introduced %python_subpackage_only so that these packages now can take advantage of the singlespec macros as well. The tracker comment on GitHub [6] has links to a few examples how to use it. - %ifpython3 and %python3_only are evil. They have been deprecated for some months already. Essentially, they fail to recognize the new flavors python36 and python38 which replace python3. OTOH, older distributions will continue to use the python3 flavor. We have introduced a new %python_provides macro, but did not modify %ifpython3 or %python3_only to incorporate this, because it is not automatically clear whether the conditioned code block shall apply to all flavors of Python3 packages or only to the primary interpreter. Replace by something like * `%if "%{python_flavor}" == "python3" || "%{?python_provides}" == "python3"` for sections only provided by the primary flavor. * `%if 0%{python_version_nodots} > 34` or `%if "%{python_flavor}" != "python2"` for section applicable to all Python 3 flavors. Cheers and happy coding, Ben [1] https://github.com/openSUSE/python-rpm-macros/issues/66 [2] https://en.opensuse.org/openSUSE:Packaging_Python [3] https://github.com/openSUSE/python-rpm-macros/blob/master/README.md [4] https://build.opensuse.org/request/show/853412 [5] https://numpy.org/neps/nep-0029-deprecation_policy.html [6] https://github.com/openSUSE/python-rpm-macros/issues/66#issuecomment-715538…

3 months, 3 weeks

3
2
0 0

2021

2020

2019

2018

openSUSE Python