Tumbleweed - Review of the week 2020/52
Dear Tumbleweed users and hackers, Xmas is upon us – at least in some areas of the world. This means quitea lot of people are away from their computers and the number of submissions is getting a bit lower. Tumbleweed is not stopping though – it just rolls at the pace contributors create submissions. For week 2020/52 this means a total of 3 snapshots that were published. Saddest of this all is that the new kernel 5.10 is not behaving very nicely when the iwlwifi module is being loaded. The three snapshots published were 1218, 1221 and 1223, containing those changes: * KDE Applications 20.12.0 * Poppler 20.12.1 * Linux kernel 5.10.1: as noted in the intro, there is an issue with iwlwifi. Unfortunately i was informed about that too late. The earlier reported amdgpu issue had been fixed in time though. Upstream but reference: https://bugzilla.kernel.org/show_bug.cgi?id=210733 * Systemd 246.9 The staging projects are still filled up and a few more snapshots are likely to be released this year. Some of the changes that might become ready include: * Mozilla Firefox 84.0 * icu 68.1: breaks a few things like postgresql. Staging:I * Ruby 3.0: final release is staged. It will be added short term as additional version, with the default, used by r.g YaST, pinned to version 2.7 * Multiple python 3 versions parallel installable. Adding to python 3.8, version 3.6 week be reintroduced. Python modules will be built for both versions. * RPM 4.16: all build issues in Staging:A have been fixed, but on upgrades, rpm seems to segfault in some cases. * brp-check-suse: a bug fix in how it detected dangling symlinks (it detected them, but did not fail as it was supposed to) * permissions package: prepares for easier listing, while supporting a full /usr merge * Rpmlint 2.0: experiments ongoing in Staging:M * openssl 3: not much progress, Staging:O still showing a lot of errors. Cheers, Dominique
Il 25/12/20 14:34, Dominique Leuenberger / DimStar ha scritto:
Dear Tumbleweed users and hackers,
Xmas is upon us – at least in some areas of the world. This means quitea lot of people are away from their computers and the number of submissions is getting a bit lower. Tumbleweed is not stopping though – it just rolls at the pace contributors create submissions. For week 2020/52 this means a total of 3 snapshots that were published. Saddest of this all is that the new kernel 5.10 is not behaving very nicely when the iwlwifi module is being loaded. The three snapshots published were 1218, 1221 and 1223, containing those changes:
* KDE Applications 20.12.0 * Poppler 20.12.1 * Linux kernel 5.10.1: as noted in the intro, there is an issue with iwlwifi. Unfortunately i was informed about that too late. The earlier reported amdgpu issue had been fixed in time though. Upstream but reference: https://bugzilla.kernel.org/show_bug.cgi?id=210733 * Systemd 246.9
The staging projects are still filled up and a few more snapshots are likely to be released this year. Some of the changes that might become ready include:
* Mozilla Firefox 84.0 * icu 68.1: breaks a few things like postgresql. Staging:I * Ruby 3.0: final release is staged. It will be added short term as additional version, with the default, used by r.g YaST, pinned to version 2.7 * Multiple python 3 versions parallel installable. Adding to python 3.8, version 3.6 week be reintroduced. Python modules will be built for both versions. * RPM 4.16: all build issues in Staging:A have been fixed, but on upgrades, rpm seems to segfault in some cases. * brp-check-suse: a bug fix in how it detected dangling symlinks (it detected them, but did not fail as it was supposed to) * permissions package: prepares for easier listing, while supporting a full /usr merge * Rpmlint 2.0: experiments ongoing in Staging:M * openssl 3: not much progress, Staging:O still showing a lot of errors.
Cheers, Dominique _______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org I hope to see soon XFCE new version available herein.
Season's greeting everybody!!! -- Marco Calistri Build: openSUSE Tumbleweed 20201223 Kernel:5.9.14-1-default Desktop: XFCE (4.14.2)
Il 25/12/20 18:15, Dominique Leuenberger / DimStar ha scritto:
On 2020-12-25 22:02, Marco Calistri wrote:
I hope to see soon XFCE new version available herein.
I might be mistaken, but i do not recall having seen submissions incoming for Tumbleweed. So i do not yet have it on the radar.
Cheers, Dominique Yes,
What I've seen was a general announce of the new XFCE 4.16 release so hopefully it will be available next also in Tumbleweed! Cheers, -- Marco Calistri Build: openSUSE Tumbleweed 20201223 Kernel:5.9.14-1-default Desktop: XFCE (4.14.2)
Am 25.12.20 um 22:32 schrieb Marco Calistri:
I might be mistaken, but i do not recall having seen submissions incoming for Tumbleweed. So i do not yet have it on the radar.
Cheers, Dominique Yes,
What I've seen was a general announce of the new XFCE 4.16 release so hopefully it will be available next also in Tumbleweed!
Lots of the 4.16 stuff is already in X11:xfce:next. So I expect it soon to be submitted to Tumbleweed as well. In the meantime if you're keen or have a spare testing machine you can try 4.16 out from xfce:next: https://build.opensuse.org/project/show/X11:xfce:next Or even xfce:rat which pulls off directly from Git: https://en.opensuse.org/Xfce_repositories#Installation Testing and bugreports are always welcome: https://en.opensuse.org/Portal:Xfce (Section "Participate") Cheers, vinz.
Il 25/12/20 19:14, Vinzenz Vietzke ha scritto:
Am 25.12.20 um 22:32 schrieb Marco Calistri:
I might be mistaken, but i do not recall having seen submissions incoming for Tumbleweed. So i do not yet have it on the radar.
Cheers, Dominique Yes,
What I've seen was a general announce of the new XFCE 4.16 release so hopefully it will be available next also in Tumbleweed!
Lots of the 4.16 stuff is already in X11:xfce:next. So I expect it soon to be submitted to Tumbleweed as well.
In the meantime if you're keen or have a spare testing machine you can try 4.16 out from xfce:next: https://build.opensuse.org/project/show/X11:xfce:next
Or even xfce:rat which pulls off directly from Git: https://en.opensuse.org/Xfce_repositories#Installation
Testing and bugreports are always welcome: https://en.opensuse.org/Portal:Xfce (Section "Participate")
Cheers, vinz.
Thanks Vinz! I've some VM machines but neither with an opensuse installed, so I prefer to wait for the official release here. Regards, -- Marco Calistri Build: openSUSE Tumbleweed 20201224 Kernel:5.10.1-1-default Desktop: XFCE (4.14.2)
On 12/26/20 5:32 AM, Marco Calistri wrote:
Il 25/12/20 18:15, Dominique Leuenberger / DimStar ha scritto:
On 2020-12-25 22:02, Marco Calistri wrote:
I hope to see soon XFCE new version available herein.
I might be mistaken, but i do not recall having seen submissions incoming for Tumbleweed. So i do not yet have it on the radar.
Cheers, Dominique Yes,
What I've seen was a general announce of the new XFCE 4.16 release so hopefully it will be available next also in Tumbleweed!
Packages are ready but we didn't think it wise to rush such updates during the Xmas weekend :D. Also there are still some programs and plugins that upstream has not released yet. We will send in the updates to Factory in the coming few days. We will also make a proper announcement as usual on ML and news-o-o. Cheers and Merry Xmas! Maurizio -- Maurizio Galli Xfce Team https://en.opensuse.org/Portal:Xfce
On Sat, Dec 26, 2020 at 5:15 AM Dominique Leuenberger / DimStar <Dimstar@opensuse.org> wrote:
On 2020-12-25 22:02, Marco Calistri wrote:
I hope to see soon XFCE new version available herein.
I might be mistaken, but i do not recall having seen submissions incoming for Tumbleweed. So i do not yet have it on the radar.
We didn't see it wise to rush such updates during the Xmas weekend :D. We will send in the updates to Factory in the coming few days. Cheers and Merry Xmas! Maurizio
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@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-7155383...
On Sat, Dec 26, 2020 at 10:02 AM Ben Greiner <code@bnavigator.de> wrote:
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@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.
I'm still not convinced this is a good idea. This fundamental change to how the Python stack works means that we will have to deal with this for all the different modules, and there are packages that deliberately don't use the "singlespec" model because it doesn't work for them (e.g. they don't use setuptools or they are an application). What is the compelling reason to fully build out the stack this way? -- 真実はいつも一つ！/ Always, there's only one truth!
Am 26.12.20 um 16:21 schrieb Neal Gompa:
On Sat, Dec 26, 2020 at 10:02 AM Ben Greiner <code@bnavigator.de> wrote:
- 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.
[...]
- %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.
I'm still not convinced this is a good idea. This fundamental change to how the Python stack works means that we will have to deal with this for all the different modules, and there are packages that deliberately don't use the "singlespec" model because it doesn't work for them (e.g. they don't use setuptools or they are an application).
Nobody has to use the singlespec model. Thankfully, nobody needs to convince you, or anybody else. But if you do use the macros, you have to use them correctly. This change has nothing to do with setuptools, and for applications see my comment about not using "%python_module" and the flavorless macros, which are -- and always have been -- singlespec.
What is the compelling reason to fully build out the stack this way?
Nothing changed in the "stack". You can continue to build against the primary python interpreter only. One reason for parallel install, which I can personally imagine, is to provide future python versions faster without switching to them as the primary python3 interpreter immediately. Python 3.9 has been released some weeks ago, but virtually no packages are built against it because many upstream projects are not ready yet. If we build against python39 in devel projects, we can detect early that a package needs work. Ben
Neal Gompa píše v So 26. 12. 2020 v 10:21 -0500:
On Sat, Dec 26, 2020 at 10:02 AM Ben Greiner <code@bnavigator.de> wrote:
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.
First of all, I would like to thank Ben for the gigantic amount of work he spent helping to make this working. Understanding our packaging macros is feat which is not simple, and he made it working mostly on his own. THANK YOU!
I'm still not convinced this is a good idea. This fundamental change to how the Python stack works means that we will have to deal with this for all the different modules, and there are packages that deliberately don't use the "singlespec" model because it doesn't work for them (e.g. they don't use setuptools or they are an application).
What is the compelling reason to fully build out the stack this way?
What Ben was saying: we have just too many stakeholders in Tumbleweed. We market OpenSUSE as “The makers’ choice for sysadmins, developers and desktop users.”, but that's slightly disingenuous because each of these groups wants something different. Let me consider these examples: * I would love to have well-tested python3* package released on the same day as it is released upstream. Not as the primary interpreter of Python, but at least with minimal set of packages (at least setuptools, pip, and pytest). That would require to have separate Staging for it or perhaps even beta version in Factory, and ability to keep those packages separate from the normal primary interpreter. We cannot do this now, obviously, because even now not all python-* packages are well working with 3.8, where the current wave of removing long-deprecated features started (the trend continues with 3.9, and it will certainly continue in 3.10). We were forced in past to patch in hurry all those packages ourselves, but the result (even after testing with full d:l:p of packages) was that every major release was minor disaster in Factory. * Obviously most people don't care about version of Python interpreter that much and they just want something reasonably recent and reasonably stable. Python 3.8 is probably the version for them at this moment. * There is however also small group of people who grumble that Factory goes too fast, and they have some good reasons why they want the oldest upstream supported version (3.6 at the moment). In OpenSUSE these are just minor grumblings, in SLE there are our customers who are paying good money for having these older versions. The same technology of using parallel versions in OpenSUSE will be used in SLE (e.g., currently we have fully synchronized SPEC files of python36 in SLE-12, SLE-15, and in Tumbleweed). * OpenSUSE is currently as far as I know the only major Linux distribution which doesn’t have PyPy at all (the package in https://build.opensuse.org/package/show/devel:languages:python:Factory/pypy3 has been broken for long time; anybody willing to pick up that challenge?). With the separate parallel packages we could put some good effort to package that as well without fear of breaking everything. * I don’t know, if it would be possible, but I still dream about having Jython as the equivalent Python interpreter (if they ever manage to have Python 3 version). This new version of packaging macros allows us to support (to some extent) these different groups at the same time. Without this substantial investment in packaging macros further development of Python packaging in Factory would be severely hampered. Thank again to Ben, and Merry Christmas to all OpenSUSE friends of good will! Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 According to the Franciscan priest Richard Rohr, spirituality is not for people who are trying to avoid hell; it is for people who have been through hell. In many ways, spirituality is about what we do with our pain. And the truth is, if we don't transform it, we will transmit it. -- Al Gustafson
participants (8)
-
Ben Greiner -
Dominique Leuenberger / DimStar -
Marco Calistri -
Matěj Cepl -
Maurizio Galli -
Maurizio Galli [m4u9] -
Neal Gompa -
Vinzenz Vietzke