13536 2019-09-18 02:26:36 +0000 Add glibc-devel-static to prerequisites on OpenSUSE based host distributions 2019-09-19 13:23:46 +0000 1 1 5 Infrastructure AutoBuilder autobuilder unspecified All Multiple RESOLVED WONTFIX Undecided normal --- 1 raj.khem richard.purdie infras.ab.watcher Infras.watcher mhalstead pidge richard.purdie --- --- Yes (doc changes required) oldest_to_newest 85001 0 raj.khem 2019-09-18 02:26:36 +0000 Some native packages do require static libc binaries on the host. Which is provided by glibc-devel on Debian and RedHat like distros and it is pulled in via either explicitly or via build-essentials dependency, but OpenSuSE has gone ahead and separated out static glibc libs into its own package called glibc-devel-static, therefore, we get inconsistent behaviour on different build hosts. see https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#required-packages-for-the-build-host We should add glibc-devel-static to pre-installed pre-requisites on OpenSuSE 85004 1 richard.purdie 2019-09-18 16:10:18 +0000 For the record I strongly disagree with this. This in one failure, we don't have other reports of this and its from a patch in the dfu-utils recipe which enables static linking. I don't agree with arbitrarily adding host dependencies to resolve issues like this. If we want to have wider discussion, reach agreement and then add tests for the presence of libc.a, fine but right now I think this recipe should be fixed. We want to minimize host systems requirements where its practical to do so. 85005 2 raj.khem 2019-09-18 16:18:40 +0000 (In reply to comment #1) > For the record I strongly disagree with this. This in one failure, we don't > have other reports of this and its from a patch in the dfu-utils recipe > which enables static linking. > dfu-utils is just showing the symptom of kind of inconsistency you have got there with prerequisites on different hosts. > I don't agree with arbitrarily adding host dependencies to resolve issues you can not call it arbitrary, there is a reason for it and why its failing as I have explained > like this. If we want to have wider discussion, reach agreement and then add > tests for the presence of libc.a, fine but right now I think this recipe > should be fixed. fixing the recipe is going to hide the underlying problem, yes it should be fixed for a different reason not the one you state. > > We want to minimize host systems requirements where its practical to do so. Thats a fair point. However, its probably helpful to call out that the prerequisites might install more or less components on different host distros, we only test a subset of metadata, therefore, these prerequisites are not a complete list that distribution might need. 85006 3 raj.khem 2019-09-18 16:18:52 +0000 (In reply to comment #1) > For the record I strongly disagree with this. This in one failure, we don't > have other reports of this and its from a patch in the dfu-utils recipe > which enables static linking. > dfu-utils is just showing the symptom of kind of inconsistency you have got there with prerequisites on different hosts. > I don't agree with arbitrarily adding host dependencies to resolve issues you can not call it arbitrary, there is a reason for it and why its failing as I have explained > like this. If we want to have wider discussion, reach agreement and then add > tests for the presence of libc.a, fine but right now I think this recipe > should be fixed. fixing the recipe is going to hide the underlying problem, yes it should be fixed for a different reason not the one you state. > > We want to minimize host systems requirements where its practical to do so. Thats a fair point. However, its probably helpful to call out that the prerequisites might install more or less components on different host distros, we only test a subset of metadata, therefore, these prerequisites are not a complete list that distribution might need. 85009 4 raj.khem 2019-09-19 13:23:46 +0000 I will close this as wontfix