[Starlingx-discuss] Several build failures due to recent code integrations
Hi all, The recent code integration in several components of StarlingX causes different build failures. I create the following stories to track the solution of these issues, in case anyone wants to take a look. https://storyboard.openstack.org/#!/story/2002779 : Kubernetes failure https://storyboard.openstack.org/#!/story/2002790 - docker-ce failure https://storyboard.openstack.org/#!/story/2002791 - etc failure https://storyboard.openstack.org/#!/story/2002792 - ntfs failure https://storyboard.openstack.org/#!/story/2002793 - puppet-collectd The root cause in all failures is the same, not adding the new needed packages into the mirror. Same thing about python src rpm reported last week. -Erich
On Mon, Jul 2, 2018 at 9:48 AM, Cordoba Malibran, Erich <erich.cordoba.malibran@intel.com> wrote:
The root cause in all failures is the same, not adding the new needed packages into the mirror. Same thing about python src rpm reported last week.
Since this is likely to be a frequent problem can we come up with a test to verify the mirror lists? I mean just make sure that our mirror source lists contain what we think they need to contain, not actually verify that the referenced packages are still available without downloading them. These would both be good to have to run locally and possibly by Zuul if we can minimize reliance on reaching external sites. dt -- Dean Troyer dtroyer@gmail.com
Great idea to verify mirror source lists. The more involved package availability tests should also be considered as part of a full release cycle validation, though. --David C -----Original Message----- From: Dean Troyer [mailto:dtroyer@gmail.com] Sent: Monday, July 2, 2018 8:34 AM To: Cordoba Malibran, Erich <erich.cordoba.malibran@intel.com> Cc: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Several build failures due to recent code integrations On Mon, Jul 2, 2018 at 9:48 AM, Cordoba Malibran, Erich <erich.cordoba.malibran@intel.com> wrote:
The root cause in all failures is the same, not adding the new needed packages into the mirror. Same thing about python src rpm reported last week.
Since this is likely to be a frequent problem can we come up with a test to verify the mirror lists? I mean just make sure that our mirror source lists contain what we think they need to contain, not actually verify that the referenced packages are still available without downloading them. These would both be good to have to run locally and possibly by Zuul if we can minimize reliance on reaching external sites. dt -- Dean Troyer dtroyer@gmail.com _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
> The root cause in all failures is the same, not adding the new needed packages into the mirror. Same thing about python src rpm reported last week.
Since this is likely to be a frequent problem can we come up with a test to verify the mirror lists? I mean just make sure that our mirror source lists contain what we think they need to contain, not actually verify that the referenced packages are still available without downloading them.
This could catch some to the problems, in particular the ones that are explicitly set in the srpm_path files. However, we still have the problem with the build requirements for every package. For example, recently Python was added to be built[0], now the src.rpm is needed. The solution here would be just to add python-2.7.5-58.el7.src.rpm into the package list. It turns out that (as detailed in another mail thread) three more packages (build dependencies) are needed to have a clean build of the python package. This is something that we can see until build time. [0] - https://review.openstack.org/#/c/578996/
On Mon, Jul 2, 2018 at 1:27 PM, Cordoba Malibran, Erich <erich.cordoba.malibran@intel.com> wrote:
This could catch some to the problems, in particular the ones that are explicitly set in the srpm_path files.
We should do that then
However, we still have the problem with the build requirements for every package. For example, recently Python was added to be built[0], now the src.rpm is needed. The solution here would be just to add python-2.7.5-58.el7.src.rpm into the package list. It turns out that (as detailed in another mail thread) three more packages (build dependencies) are needed to have a clean build of the python package. This is something that we can see until build time.
Actually you can get an SRPM's build dependencies and check to see that they are already accounted for. As long as we have multiple lists of packages we need to do sanity checking to ensure they are consistent with each other. This isn't going to catch everything of course, but it can catch some things early when the cycle time is short and not hours to do a build. dt -- Dean Troyer dtroyer@gmail.com
participants (3)
-
Cobbley, David A
-
Cordoba Malibran, Erich
-
Dean Troyer