Hi infra, Another failure caused by missing cpopen: http://jenkins.ovirt.org/job/vdsm_unit_tests_gerrit/6477/testReport/junit/no... Can you check this?
and again this is caused by vdsm-python-cpopen installed on the host by another job probably. so either vdsm will fix this in the spec file so it will not conflict with each other, or we need to find who's installing the vdsm-python-cpopen pkg. Eyal. ----- Original Message -----
From: "Nir Soffer" <nsoffer@redhat.com> To: infra@ovirt.org Sent: Wednesday, January 1, 2014 12:23:44 PM Subject: Another cpopen missing failure
Hi infra,
Another failure caused by missing cpopen: http://jenkins.ovirt.org/job/vdsm_unit_tests_gerrit/6477/testReport/junit/no...
Can you check this? _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
----- Original Message -----
From: "Eyal Edri" <eedri@redhat.com> To: "Nir Soffer" <nsoffer@redhat.com> Cc: infra@ovirt.org, "David Caro Estevez" <dcaroest@redhat.com> Sent: Wednesday, January 1, 2014 1:06:11 PM Subject: Re: Another cpopen missing failure
and again this is caused by vdsm-python-cpopen installed on the host by another job probably. so either vdsm will fix this in the spec file so it will not conflict with each other,
or we need to find who's installing the vdsm-python-cpopen pkg.
This never ends :-) How can we prevent such issues in the future?
Eyal.
----- Original Message -----
From: "Nir Soffer" <nsoffer@redhat.com> To: infra@ovirt.org Sent: Wednesday, January 1, 2014 12:23:44 PM Subject: Another cpopen missing failure
Hi infra,
Another failure caused by missing cpopen: http://jenkins.ovirt.org/job/vdsm_unit_tests_gerrit/6477/testReport/junit/no...
Can you check this? _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
i still think it's a problem with vdsm master (of one of it's deps) bring it: http://jenkins.ovirt.org/job/vdsm_master_install_rpm_sanity_gerrit/label=fed... Marking /home/jenkins/workspace/vdsm_master_install_rpm_sanity_gerrit/label/fedora19/rpms/vdsm-python-zombiereaper-4.13.0-274.git4f2c481.fc19.noarch.rpm to be installed Resolving Dependencies --> Running transaction check ---> Package vdsm.x86_64 0:4.13.0-274.git4f2c481.fc19 will be installed --> Processing Dependency: python-cpopen >= 1.2.3-5 for package: vdsm-4.13.0-274.git4f2c481.fc19.x86_64 ---> Package vdsm-python.x86_64 0:4.13.0-274.git4f2c481.fc19 will be installed ---> Package vdsm-python-zombiereaper.noarch 0:4.13.0-274.git4f2c481.fc19 will be installed ---> Package vdsm-xmlrpc.noarch 0:4.13.0-274.git4f2c481.fc19 will be installed --> Running transaction check ---> Package vdsm-python-cpopen.x86_64 0:4.13.2-1.fc19 will be installed --> Finished Dependency Resolution ----- Original Message -----
From: "Nir Soffer" <nsoffer@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: infra@ovirt.org, "David Caro Estevez" <dcaroest@redhat.com>, "Yaniv Bronheim" <ybronhei@redhat.com>, "Dan Kenigsberg" <danken@redhat.com> Sent: Wednesday, January 1, 2014 1:12:44 PM Subject: Re: Another cpopen missing failure
----- Original Message -----
From: "Eyal Edri" <eedri@redhat.com> To: "Nir Soffer" <nsoffer@redhat.com> Cc: infra@ovirt.org, "David Caro Estevez" <dcaroest@redhat.com> Sent: Wednesday, January 1, 2014 1:06:11 PM Subject: Re: Another cpopen missing failure
and again this is caused by vdsm-python-cpopen installed on the host by another job probably. so either vdsm will fix this in the spec file so it will not conflict with each other,
or we need to find who's installing the vdsm-python-cpopen pkg.
This never ends :-)
How can we prevent such issues in the future?
Eyal.
----- Original Message -----
From: "Nir Soffer" <nsoffer@redhat.com> To: infra@ovirt.org Sent: Wednesday, January 1, 2014 12:23:44 PM Subject: Another cpopen missing failure
Hi infra,
Another failure caused by missing cpopen: http://jenkins.ovirt.org/job/vdsm_unit_tests_gerrit/6477/testReport/junit/no...
Can you check this? _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
I think it's a problem that puppet still tries to install python-cpopen which is wrong and the reason jenkins-slave-vm01 keeps going into the puppet error state: <<<EOF change from absent to latest failed: Could not update: Execution of '/usr/bin/yum -d 0 -e 0 -y install python-cpopen' returned 1: Transaction check error: file /usr/lib64/python2.7/site-packages/cpopen/__init__.py from install of python-cpopen-1.2.3-4.fc19.x86_64 conflicts with file from package vdsm-python-cpopen-4.13.2-1.fc19.x86_64 file /usr/lib64/python2.7/site-packages/cpopen/__init__.pyc from install of python-cpopen-1.2.3-4.fc19.x86_64 conflicts with file from package vdsm-python-cpopen-4.13.2-1.fc19.x86_64 file /usr/lib64/python2.7/site-packages/cpopen/__init__.pyo from install of python-cpopen-1.2.3-4.fc19.x86_64 conflicts with file from package vdsm-python-cpopen-4.13.2-1.fc19.x86_64 file /usr/lib64/python2.7/site-packages/cpopen/cpopen.so from install of python-cpopen-1.2.3-4.fc19.x86_64 conflicts with file from package vdsm-python-cpopen-4.13.2-1.fc19.x86_64 Error Summary ------------- EOF I thinkt he solution is to re-submit http://gerrit.ovirt.org/22140 against production and have the VDSM job ensure the proper version is installed or ensure either version can be used so we no longer need vdsm-python-cpopen at all. Puppet enforces state and if a jenkins job needs a variable state (ie sometimes X, sometimes Y), puppet is the wrong tool to use and it becomes the jobs responsibility. On Wed, Jan 01, 2014 at 07:07:34AM -0500, Eyal Edri wrote:
i still think it's a problem with vdsm master (of one of it's deps) bring it: http://jenkins.ovirt.org/job/vdsm_master_install_rpm_sanity_gerrit/label=fed...
Marking /home/jenkins/workspace/vdsm_master_install_rpm_sanity_gerrit/label/fedora19/rpms/vdsm-python-zombiereaper-4.13.0-274.git4f2c481.fc19.noarch.rpm to be installed Resolving Dependencies --> Running transaction check ---> Package vdsm.x86_64 0:4.13.0-274.git4f2c481.fc19 will be installed --> Processing Dependency: python-cpopen >= 1.2.3-5 for package: vdsm-4.13.0-274.git4f2c481.fc19.x86_64 ---> Package vdsm-python.x86_64 0:4.13.0-274.git4f2c481.fc19 will be installed ---> Package vdsm-python-zombiereaper.noarch 0:4.13.0-274.git4f2c481.fc19 will be installed ---> Package vdsm-xmlrpc.noarch 0:4.13.0-274.git4f2c481.fc19 will be installed --> Running transaction check ---> Package vdsm-python-cpopen.x86_64 0:4.13.2-1.fc19 will be installed --> Finished Dependency Resolution
----- Original Message -----
From: "Nir Soffer" <nsoffer@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: infra@ovirt.org, "David Caro Estevez" <dcaroest@redhat.com>, "Yaniv Bronheim" <ybronhei@redhat.com>, "Dan Kenigsberg" <danken@redhat.com> Sent: Wednesday, January 1, 2014 1:12:44 PM Subject: Re: Another cpopen missing failure
----- Original Message -----
From: "Eyal Edri" <eedri@redhat.com> To: "Nir Soffer" <nsoffer@redhat.com> Cc: infra@ovirt.org, "David Caro Estevez" <dcaroest@redhat.com> Sent: Wednesday, January 1, 2014 1:06:11 PM Subject: Re: Another cpopen missing failure
and again this is caused by vdsm-python-cpopen installed on the host by another job probably. so either vdsm will fix this in the spec file so it will not conflict with each other,
or we need to find who's installing the vdsm-python-cpopen pkg.
This never ends :-)
How can we prevent such issues in the future?
Eyal.
----- Original Message -----
From: "Nir Soffer" <nsoffer@redhat.com> To: infra@ovirt.org Sent: Wednesday, January 1, 2014 12:23:44 PM Subject: Another cpopen missing failure
Hi infra,
Another failure caused by missing cpopen: http://jenkins.ovirt.org/job/vdsm_unit_tests_gerrit/6477/testReport/junit/no...
Can you check this? _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
the problem is that one vdsm jobs needs python-cpopen (like unit tests), while another job (like vdsm install sanity) fails on it cause of conflict with vdsm-python-cpopen, so puppet does what it should like all other pkg. what's wrong is: 1. why vdsm still builds vdsm-python-cpopen if it's not needed 2. why spec file brings it when you try to install python-cpopen. e. ----- Original Message -----
From: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt@kohlvanwijngaarden.nl> To: "Eyal Edri" <eedri@redhat.com> Cc: "Nir Soffer" <nsoffer@redhat.com>, infra@ovirt.org Sent: Wednesday, January 1, 2014 7:52:36 PM Subject: Re: Another cpopen missing failure
I think it's a problem that puppet still tries to install python-cpopen which is wrong and the reason jenkins-slave-vm01 keeps going into the puppet error state:
<<<EOF change from absent to latest failed: Could not update: Execution of '/usr/bin/yum -d 0 -e 0 -y install python-cpopen' returned 1:
Transaction check error: file /usr/lib64/python2.7/site-packages/cpopen/__init__.py from install of python-cpopen-1.2.3-4.fc19.x86_64 conflicts with file from package vdsm-python-cpopen-4.13.2-1.fc19.x86_64 file /usr/lib64/python2.7/site-packages/cpopen/__init__.pyc from install of python-cpopen-1.2.3-4.fc19.x86_64 conflicts with file from package vdsm-python-cpopen-4.13.2-1.fc19.x86_64 file /usr/lib64/python2.7/site-packages/cpopen/__init__.pyo from install of python-cpopen-1.2.3-4.fc19.x86_64 conflicts with file from package vdsm-python-cpopen-4.13.2-1.fc19.x86_64 file /usr/lib64/python2.7/site-packages/cpopen/cpopen.so from install of python-cpopen-1.2.3-4.fc19.x86_64 conflicts with file from package vdsm-python-cpopen-4.13.2-1.fc19.x86_64
Error Summary ------------- EOF
I thinkt he solution is to re-submit http://gerrit.ovirt.org/22140 against production and have the VDSM job ensure the proper version is installed or ensure either version can be used so we no longer need vdsm-python-cpopen at all. Puppet enforces state and if a jenkins job needs a variable state (ie sometimes X, sometimes Y), puppet is the wrong tool to use and it becomes the jobs responsibility.
On Wed, Jan 01, 2014 at 07:07:34AM -0500, Eyal Edri wrote:
i still think it's a problem with vdsm master (of one of it's deps) bring it: http://jenkins.ovirt.org/job/vdsm_master_install_rpm_sanity_gerrit/label=fed...
Marking /home/jenkins/workspace/vdsm_master_install_rpm_sanity_gerrit/label/fedora19/rpms/vdsm-python-zombiereaper-4.13.0-274.git4f2c481.fc19.noarch.rpm to be installed Resolving Dependencies --> Running transaction check ---> Package vdsm.x86_64 0:4.13.0-274.git4f2c481.fc19 will be installed --> Processing Dependency: python-cpopen >= 1.2.3-5 for package: vdsm-4.13.0-274.git4f2c481.fc19.x86_64 ---> Package vdsm-python.x86_64 0:4.13.0-274.git4f2c481.fc19 will be installed ---> Package vdsm-python-zombiereaper.noarch 0:4.13.0-274.git4f2c481.fc19 will be installed ---> Package vdsm-xmlrpc.noarch 0:4.13.0-274.git4f2c481.fc19 will be installed --> Running transaction check ---> Package vdsm-python-cpopen.x86_64 0:4.13.2-1.fc19 will be installed --> Finished Dependency Resolution
----- Original Message -----
From: "Nir Soffer" <nsoffer@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: infra@ovirt.org, "David Caro Estevez" <dcaroest@redhat.com>, "Yaniv Bronheim" <ybronhei@redhat.com>, "Dan Kenigsberg" <danken@redhat.com> Sent: Wednesday, January 1, 2014 1:12:44 PM Subject: Re: Another cpopen missing failure
----- Original Message -----
From: "Eyal Edri" <eedri@redhat.com> To: "Nir Soffer" <nsoffer@redhat.com> Cc: infra@ovirt.org, "David Caro Estevez" <dcaroest@redhat.com> Sent: Wednesday, January 1, 2014 1:06:11 PM Subject: Re: Another cpopen missing failure
and again this is caused by vdsm-python-cpopen installed on the host by another job probably. so either vdsm will fix this in the spec file so it will not conflict with each other,
or we need to find who's installing the vdsm-python-cpopen pkg.
This never ends :-)
How can we prevent such issues in the future?
Eyal.
----- Original Message -----
From: "Nir Soffer" <nsoffer@redhat.com> To: infra@ovirt.org Sent: Wednesday, January 1, 2014 12:23:44 PM Subject: Another cpopen missing failure
Hi infra,
Another failure caused by missing cpopen: http://jenkins.ovirt.org/job/vdsm_unit_tests_gerrit/6477/testReport/junit/no...
Can you check this? _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
On Wed, Jan 01, 2014 at 02:10:54PM -0500, Eyal Edri wrote:
the problem is that one vdsm jobs needs python-cpopen (like unit tests), while another job (like vdsm install sanity) fails on it cause of conflict with vdsm-python-cpopen, so puppet does what it should like all other pkg.
what's wrong is: 1. why vdsm still builds vdsm-python-cpopen if it's not needed
Do you really want to change this for released / still supported versions?
2. why spec file brings it when you try to install python-cpopen.
e.
----- Original Message -----
From: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt@kohlvanwijngaarden.nl> To: "Eyal Edri" <eedri@redhat.com> Cc: "Nir Soffer" <nsoffer@redhat.com>, infra@ovirt.org Sent: Wednesday, January 1, 2014 7:52:36 PM Subject: Re: Another cpopen missing failure
I think it's a problem that puppet still tries to install python-cpopen which is wrong and the reason jenkins-slave-vm01 keeps going into the puppet error state:
<<<EOF change from absent to latest failed: Could not update: Execution of '/usr/bin/yum -d 0 -e 0 -y install python-cpopen' returned 1:
Transaction check error: file /usr/lib64/python2.7/site-packages/cpopen/__init__.py from install of python-cpopen-1.2.3-4.fc19.x86_64 conflicts with file from package vdsm-python-cpopen-4.13.2-1.fc19.x86_64 file /usr/lib64/python2.7/site-packages/cpopen/__init__.pyc from install of python-cpopen-1.2.3-4.fc19.x86_64 conflicts with file from package vdsm-python-cpopen-4.13.2-1.fc19.x86_64 file /usr/lib64/python2.7/site-packages/cpopen/__init__.pyo from install of python-cpopen-1.2.3-4.fc19.x86_64 conflicts with file from package vdsm-python-cpopen-4.13.2-1.fc19.x86_64 file /usr/lib64/python2.7/site-packages/cpopen/cpopen.so from install of python-cpopen-1.2.3-4.fc19.x86_64 conflicts with file from package vdsm-python-cpopen-4.13.2-1.fc19.x86_64
Error Summary ------------- EOF
I thinkt he solution is to re-submit http://gerrit.ovirt.org/22140 against production and have the VDSM job ensure the proper version is installed or ensure either version can be used so we no longer need vdsm-python-cpopen at all. Puppet enforces state and if a jenkins job needs a variable state (ie sometimes X, sometimes Y), puppet is the wrong tool to use and it becomes the jobs responsibility.
On Wed, Jan 01, 2014 at 07:07:34AM -0500, Eyal Edri wrote:
i still think it's a problem with vdsm master (of one of it's deps) bring it: http://jenkins.ovirt.org/job/vdsm_master_install_rpm_sanity_gerrit/label=fed...
Marking /home/jenkins/workspace/vdsm_master_install_rpm_sanity_gerrit/label/fedora19/rpms/vdsm-python-zombiereaper-4.13.0-274.git4f2c481.fc19.noarch.rpm to be installed Resolving Dependencies --> Running transaction check ---> Package vdsm.x86_64 0:4.13.0-274.git4f2c481.fc19 will be installed --> Processing Dependency: python-cpopen >= 1.2.3-5 for package: vdsm-4.13.0-274.git4f2c481.fc19.x86_64 ---> Package vdsm-python.x86_64 0:4.13.0-274.git4f2c481.fc19 will be installed ---> Package vdsm-python-zombiereaper.noarch 0:4.13.0-274.git4f2c481.fc19 will be installed ---> Package vdsm-xmlrpc.noarch 0:4.13.0-274.git4f2c481.fc19 will be installed --> Running transaction check ---> Package vdsm-python-cpopen.x86_64 0:4.13.2-1.fc19 will be installed --> Finished Dependency Resolution
----- Original Message -----
From: "Nir Soffer" <nsoffer@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: infra@ovirt.org, "David Caro Estevez" <dcaroest@redhat.com>, "Yaniv Bronheim" <ybronhei@redhat.com>, "Dan Kenigsberg" <danken@redhat.com> Sent: Wednesday, January 1, 2014 1:12:44 PM Subject: Re: Another cpopen missing failure
----- Original Message -----
From: "Eyal Edri" <eedri@redhat.com> To: "Nir Soffer" <nsoffer@redhat.com> Cc: infra@ovirt.org, "David Caro Estevez" <dcaroest@redhat.com> Sent: Wednesday, January 1, 2014 1:06:11 PM Subject: Re: Another cpopen missing failure
and again this is caused by vdsm-python-cpopen installed on the host by another job probably. so either vdsm will fix this in the spec file so it will not conflict with each other,
or we need to find who's installing the vdsm-python-cpopen pkg.
This never ends :-)
How can we prevent such issues in the future?
Eyal.
----- Original Message -----
From: "Nir Soffer" <nsoffer@redhat.com> To: infra@ovirt.org Sent: Wednesday, January 1, 2014 12:23:44 PM Subject: Another cpopen missing failure
Hi infra,
Another failure caused by missing cpopen: http://jenkins.ovirt.org/job/vdsm_unit_tests_gerrit/6477/testReport/junit/no...
Can you check this? _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
On Wed, Jan 01, 2014 at 02:10:54PM -0500, Eyal Edri wrote:
the problem is that one vdsm jobs needs python-cpopen (like unit tests), while another job (like vdsm install sanity) fails on it cause of conflict with vdsm-python-cpopen, so puppet does what it should like all other pkg.
what's wrong is: 1. why vdsm still builds vdsm-python-cpopen if it's not needed
ovirt-3.3's Vdsm builds vdsm-python-cpopen - as it always has and always will. We cannot change history, and we shouldn't make such a change in a stable branch. master's Vdsm does not build that package and does not require it.
2. why spec file brings it when you try to install python-cpopen.
http://resources.ovirt.org/releases/updates-testing/rpm/Fedora/19/x86_64/ is enabled on that slave, and it carries vdsm-python-4.13.2-1.fc19.x86_64.rpm which provides python-cpopen=1.2.3 Yum prefers to take it over the available version from fedora. This might be related to the fact that https://admin.fedoraproject.org/updates/FEDORA-2013-23216/python-cpopen-1.2.... is stuck in testing mode for quite some time. Your karma may hasten things there. I share Ewoud's opinion: since some jobs need python-cpopen and some conflict with it, it should not be part of the platform handled by puppet, but job-specific. On the mean while we should disable the updates-testing repo, or drop the old ovirt-3.3 stuff from it, or put python-cpopen-1.2.3-5 there. Dan.
ok, sandro - can we update the ovirt-testing repo with the latest pkg? or remove the offending one? eyal. ----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt@kohlvanwijngaarden.nl>, infra@ovirt.org Sent: Thursday, January 2, 2014 4:50:45 PM Subject: Re: Another cpopen missing failure
On Wed, Jan 01, 2014 at 02:10:54PM -0500, Eyal Edri wrote:
the problem is that one vdsm jobs needs python-cpopen (like unit tests), while another job (like vdsm install sanity) fails on it cause of conflict with vdsm-python-cpopen, so puppet does what it should like all other pkg.
what's wrong is: 1. why vdsm still builds vdsm-python-cpopen if it's not needed
ovirt-3.3's Vdsm builds vdsm-python-cpopen - as it always has and always will. We cannot change history, and we shouldn't make such a change in a stable branch.
master's Vdsm does not build that package and does not require it.
2. why spec file brings it when you try to install python-cpopen.
http://resources.ovirt.org/releases/updates-testing/rpm/Fedora/19/x86_64/ is enabled on that slave, and it carries vdsm-python-4.13.2-1.fc19.x86_64.rpm which provides python-cpopen=1.2.3
Yum prefers to take it over the available version from fedora. This might be related to the fact that https://admin.fedoraproject.org/updates/FEDORA-2013-23216/python-cpopen-1.2.... is stuck in testing mode for quite some time. Your karma may hasten things there.
I share Ewoud's opinion: since some jobs need python-cpopen and some conflict with it, it should not be part of the platform handled by puppet, but job-specific.
On the mean while we should disable the updates-testing repo, or drop the old ovirt-3.3 stuff from it, or put python-cpopen-1.2.3-5 there.
Dan.
update: i tested this with new python-cpopen and it seems to work. so i guess we should push the new version into fedora and el soon to resolve this. Eyal. ----- Original Message -----
From: "Eyal Edri" <eedri@redhat.com> To: "Dan Kenigsberg" <danken@redhat.com>, "Sandro Bonazzola" <sbonazzo@redhat.com>, "Kiril Nesenko" <knesenko@redhat.com> Cc: infra@ovirt.org Sent: Thursday, January 2, 2014 5:29:29 PM Subject: Re: Another cpopen missing failure
ok,
sandro - can we update the ovirt-testing repo with the latest pkg? or remove the offending one?
eyal.
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt@kohlvanwijngaarden.nl>, infra@ovirt.org Sent: Thursday, January 2, 2014 4:50:45 PM Subject: Re: Another cpopen missing failure
On Wed, Jan 01, 2014 at 02:10:54PM -0500, Eyal Edri wrote:
the problem is that one vdsm jobs needs python-cpopen (like unit tests), while another job (like vdsm install sanity) fails on it cause of conflict with vdsm-python-cpopen, so puppet does what it should like all other pkg.
what's wrong is: 1. why vdsm still builds vdsm-python-cpopen if it's not needed
ovirt-3.3's Vdsm builds vdsm-python-cpopen - as it always has and always will. We cannot change history, and we shouldn't make such a change in a stable branch.
master's Vdsm does not build that package and does not require it.
2. why spec file brings it when you try to install python-cpopen.
http://resources.ovirt.org/releases/updates-testing/rpm/Fedora/19/x86_64/ is enabled on that slave, and it carries vdsm-python-4.13.2-1.fc19.x86_64.rpm which provides python-cpopen=1.2.3
Yum prefers to take it over the available version from fedora. This might be related to the fact that https://admin.fedoraproject.org/updates/FEDORA-2013-23216/python-cpopen-1.2.... is stuck in testing mode for quite some time. Your karma may hasten things there.
I share Ewoud's opinion: since some jobs need python-cpopen and some conflict with it, it should not be part of the platform handled by puppet, but job-specific.
On the mean while we should disable the updates-testing repo, or drop the old ovirt-3.3 stuff from it, or put python-cpopen-1.2.3-5 there.
Dan.
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Il 02/01/2014 16:29, Eyal Edri ha scritto:
ok,
sandro - can we update the ovirt-testing repo with the latest pkg? or remove the offending one?
since everything in ovirt-testing should have been moved to ovirt-stable after 3.3.2 release (we had no rc2 release), I think you can safely remove ovirt-testing content.
eyal.
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt@kohlvanwijngaarden.nl>, infra@ovirt.org Sent: Thursday, January 2, 2014 4:50:45 PM Subject: Re: Another cpopen missing failure
On Wed, Jan 01, 2014 at 02:10:54PM -0500, Eyal Edri wrote:
the problem is that one vdsm jobs needs python-cpopen (like unit tests), while another job (like vdsm install sanity) fails on it cause of conflict with vdsm-python-cpopen, so puppet does what it should like all other pkg.
what's wrong is: 1. why vdsm still builds vdsm-python-cpopen if it's not needed
ovirt-3.3's Vdsm builds vdsm-python-cpopen - as it always has and always will. We cannot change history, and we shouldn't make such a change in a stable branch.
master's Vdsm does not build that package and does not require it.
2. why spec file brings it when you try to install python-cpopen.
http://resources.ovirt.org/releases/updates-testing/rpm/Fedora/19/x86_64/ is enabled on that slave, and it carries vdsm-python-4.13.2-1.fc19.x86_64.rpm which provides python-cpopen=1.2.3
Yum prefers to take it over the available version from fedora. This might be related to the fact that https://admin.fedoraproject.org/updates/FEDORA-2013-23216/python-cpopen-1.2.... is stuck in testing mode for quite some time. Your karma may hasten things there.
I share Ewoud's opinion: since some jobs need python-cpopen and some conflict with it, it should not be part of the platform handled by puppet, but job-specific.
On the mean while we should disable the updates-testing repo, or drop the old ovirt-3.3 stuff from it, or put python-cpopen-1.2.3-5 there.
Dan.
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
participants (5)
-
Dan Kenigsberg -
Ewoud Kohl van Wijngaarden -
Eyal Edri -
Nir Soffer -
Sandro Bonazzola