Leap builds - another inconsistency for python-builds
Hi, I have one package (python-pydyf) in d:l:p and in two other repos with basically the same prjconf. In one it builds, in another one its broken for 15.3, but still builds locally! In this case it fails in testing: Direct construction of IsortItem has been deprecated, please use IsortItem.from_parent. ...although pyproject.toml is patched: [tool.pytest.ini_options] addopts = '--isort --flake8 --cov --no-cov-on-fail' beside this case, I would be interested why a package build locally but sometimes on OBS, sometimes not.... Any ideas? Thanks! Axel
On 2022-01-13 13:48:58 +0100, Axel Braun wrote:
I have one package (python-pydyf) in d:l:p and in two other repos with basically the same prjconf. In one it builds, in another one its broken for 15.3, but still builds locally!
Hmm can you please name the other projects, too? The current description is a bit imprecise ("basically" the same prjconf, broken == build failure or broken == prjconf misconfiguration? etc.).
In this case it fails in testing:
Direct construction of IsortItem has been deprecated, please use IsortItem.from_parent.
...although pyproject.toml is patched: [tool.pytest.ini_options] addopts = '--isort --flake8 --cov --no-cov-on-fail'
beside this case, I would be interested why a package build locally but sometimes on OBS, sometimes not....
Maybe the testcase itself is racy/flaky? (Just a wildguess... I did not have a look at the package/code...). Do you perform a local chroot-based or KVM-based build? Marcus
Hello Marcus, Am Donnerstag, 13. Januar 2022, 18:56:54 CET schrieb Marcus Hüwe:
On 2022-01-13 13:48:58 +0100, Axel Braun wrote:
I have one package (python-pydyf) in d:l:p and in two other repos with basically the same prjconf. In one it builds, in another one its broken for 15.3, but still builds locally!
Hmm can you please name the other projects, too? The current description is a bit imprecise ("basically" the same prjconf, broken == build failure or broken == prjconf misconfiguration? etc.).
python-pydyf build in d:l:p and Application:ERP:GNUHealth:4.0 Does not build in Application:ERP:Tryton:6.0, but builds locally
beside this case, I would be interested why a package build locally but sometimes on OBS, sometimes not....
Maybe the testcase itself is racy/flaky? (Just a wildguess... I did not have a look at the package/code...). Do you perform a local chroot-based or KVM-based build?
Dafault ist kvm I guess Cheers Axel
On 2022-01-13 19:03:45 +0100, Axel Braun wrote:
Am Donnerstag, 13. Januar 2022, 18:56:54 CET schrieb Marcus Hüwe:
On 2022-01-13 13:48:58 +0100, Axel Braun wrote:
I have one package (python-pydyf) in d:l:p and in two other repos with basically the same prjconf. In one it builds, in another one its broken for 15.3, but still builds locally!
Hmm can you please name the other projects, too? The current description is a bit imprecise ("basically" the same prjconf, broken == build failure or broken == prjconf misconfiguration? etc.).
python-pydyf build in d:l:p and Application:ERP:GNUHealth:4.0
Does not build in Application:ERP:Tryton:6.0, but builds locally
Hmm Application:ERP:Tryton:6.0 and Application:ERP:GNUHealth:4.0 have different 15.3 repos configured. The latter also includes openSUSE:Backports:SLE-15-SP3:Update. That is, the build environments in both projects are different. For instance, compare osc buildinfo Application:ERP:Tryton:6.0 python-pydyf 15.3 x86_64 with osc buildinfo Application:ERP:GNUHealth:4.0 python-pydyf 15.3 x86_64
beside this case, I would be interested why a package build locally but sometimes on OBS, sometimes not....
Maybe the testcase itself is racy/flaky? (Just a wildguess... I did not have a look at the package/code...). Do you perform a local chroot-based or KVM-based build?
Dafault ist kvm I guess
The default is a chroot-based build (unless you configured something else in your oscrc). You could try a local KVM-based build of the Application:ERP:Tryton:6.0/python-pydyf package and check if it also fails. Marcus
Am Donnerstag, 13. Januar 2022, 19:29:38 CET schrieb Marcus Hüwe:
On 2022-01-13 19:03:45 +0100, Axel Braun wrote:
Am Donnerstag, 13. Januar 2022, 18:56:54 CET schrieb Marcus Hüwe:
On 2022-01-13 13:48:58 +0100, Axel Braun wrote:
I have one package (python-pydyf) in d:l:p and in two other repos with basically the same prjconf. In one it builds, in another one its broken for 15.3, but still builds locally!
Hmm can you please name the other projects, too? The current description is a bit imprecise ("basically" the same prjconf, broken == build failure or broken == prjconf misconfiguration? etc.).
python-pydyf build in d:l:p and Application:ERP:GNUHealth:4.0
Does not build in Application:ERP:Tryton:6.0, but builds locally
Hmm Application:ERP:Tryton:6.0 and Application:ERP:GNUHealth:4.0 have different 15.3 repos configured. The latter also includes openSUSE:Backports:SLE-15-SP3:Update. That is, the build environments in both projects are different.
Correct, seems I missed that in the back and forth of python repos for 15.3 the last days (you may remember the thread on factory-ML) However openSUSE:Backports:SLE-15-SP3:Update is included in openSUSE:Leap:15.3:Update and removing the backports-repo does not have an impact. A:E:G:4.0 still builds
For instance, compare
osc buildinfo Application:ERP:Tryton:6.0 python-pydyf 15.3 x86_64 with osc buildinfo Application:ERP:GNUHealth:4.0 python-pydyf 15.3 x86_64
In fact the versions in A:E:G:4 are mostly older than in A:E:T:6, as some of the other python packages in A:E:T:6 require more recent packages: setuptools, pytest, py. What I could spot that python-six is not pulled-in in A:E:T:6. Not sure if this is the only difference. But on the other hand, it builds fine for TW, which has recent tools as well.
beside this case, I would be interested why a package build locally but sometimes on OBS, sometimes not....
Maybe the testcase itself is racy/flaky? (Just a wildguess... I did not have a look at the package/code...). Do you perform a local chroot-based or KVM-based build?
Dafault ist kvm I guess
The default is a chroot-based build (unless you configured something else in your oscrc). You could try a local KVM-based build of the Application:ERP:Tryton:6.0/python-pydyf package and check if it also fails.
right, it is default : chroot Best, Axel
participants (2)
-
Axel Braun -
Marcus Hüwe