On 23.05.2012 [14:47:44 -0300], Lucas Meneghel Rodrigues wrote: > On Wed, 2012-05-23 at 14:37 -0300, Cleber Rosa wrote: > > On 05/23/2012 02:22 PM, Lucas Meneghel Rodrigues wrote: > > > On Wed, 2012-05-23 at 14:06 -0300, Cleber Rosa wrote: > > >> On 05/17/2012 09:41 PM, Lucas Meneghel Rodrigues wrote: > > >>> On Thu, 2012-05-17 at 17:01 -0700, Nishanth Aravamudan wrote: > > >>>> On 17.05.2012 [20:56:40 -0300], Lucas Meneghel Rodrigues wrote: > > >>>>> On Thu, 2012-05-17 at 16:44 -0700, Nishanth Aravamudan wrote: > > >>>>>> Hi Lucas, > > >>>>>> > > >>>>>> client job reports: > > >>>>>> > > >>>>>> 05/17 19:36:13 WARNI| boottool:0567| version 8.3 being used is not > > >>>>>> guaranteed to work properly. Mininum required version is 8.11. > > >>>>>> 05/17 19:36:13 INFO | boottool:0503| Installing grubby because > > >>>>>> currently installed version (8.3) is not recent enough > > >>>>>> 05/17 19:36:15 DEBUG| boottool:1251| Failed to build grubby during > > >>>>>> "make" step > > >>>>>> 05/17 19:36:15 DEBUG| boottool:1239| grubby.c:28:18: fatal error: > > >>>>>> popt.h: No such file or directory > > >>>>>> 05/17 19:36:15 DEBUG| boottool:1239| compilation terminated. > > >>>>>> 05/17 19:36:15 DEBUG| boottool:1239| make: *** [grubby.o] Error 1 > > >>>>>> 05/17 19:36:15 ERROR| job:1330| JOB ERROR: Unable to > > >>>>>> instantiate boottool > > >>>>>> 05/17 19:36:15 INFO | job:0210| END ABORT ---- ---- > > >>>>>> timestamp=1337297775 localtime=May 17 19:36:15 Unable to > > >>>>>> instantiate boottool > > >>>>>> > > >>>>>> Thoughts? > > >>>>>> > > >>>>>> Seems like maybe I'm missing popt-devel? But I don't think the > > >>>>>> autotest > > >>>>> Yes, popt-devel is required to build grubby. > > >>>>> > > >>>>>> harness should require me to change my kickstarts (although I am > > >>>>>> happy > > >>>>>> to do so) to add that package. Is it possible to, from w/in autotest, > > >>>>>> automatically install that package as a dependency? > > >>>>> We still don't have this support. We wrote a tool to act as an > > >>>>> abstraction layer for package managers: > > >>>>> > > >>>>> https://github.com/autotest/autotest/blob/master/client/shared/software_manager.py > > >>>>> > > >>>>> That code could make possible what you describe, however I never got > > >>>>> around using it inside autotest (yet another pending task) > > >>>>> > > >>>>> https://github.com/autotest/autotest/issues/350 > > >>>>> > > >>>>> So, for now, it's advisable to add popt-devel to the kickstarts you > > >>>>> have. > > >>>>> > > >>>>> Sorry about the inconvenience :( > > >>>> No problem, adding it now. Could we perhaps check to see if it's > > >>>> installed in the "installing grubby" check and not bother building if > > >>>> we > > >>>> can't find it? > > >>> Fair enough. I've just sent a patch that does this. I'd need to test > > >>> before applying it, but in any case, we're on a good track. > > >> libblkid-devel and libuuid-devel are also build deps. > > >> > > >> The question is how deep should we go looking and checking those deps? > > >> make, gcc, glibc-devel, etc also come to my mind. > > > Sure, I understand what you meant, fair enough. If you feel inclined, > > > please send a patch reverting the change: > > > > What I really meant was to call for some kind of decision on that, which > > I myself could not reach alone :) > > > > Also, I anticipated that even after having that patch applied, our users > > would get yet another failure, after all, popt.h ought to be more > > commonly installed than stuff such as libblkid and libuuid headers. > > > > The use of software manager does indeed looks like a nice solution for > > autotest, but not so much for boottool as an standalone tool (which > > still holds true when running server code). > > > > So, I don't think we should revert your patch, quite the contrary. Until > > we have a better solution, I think we should add checks for these other > > key header files. > > Ok, so one of us (lmr/cleber/nacc) should change a patch adding checks > for the other headers (libblkid and libuuid) and then call it a day :)
I completely get Cleber's point -- and there must be some logical base installation requirement (gcc, make fall into that category, IMO) dependency chain to indicate what is needed for autotest generally to be useful, and then there might be packages/libs specific tools (like boottool depend on). Another option would perhaps to add a ./configure step to boottool's build process like other tools have and have that check for the various libraries & dependencies. Then we'd get clean output in the logs of what the problem is, still failing the job, rather than make failures (which can be noisy). Thanks, Nish -- Nishanth Aravamudan <[email protected]> IBM Linux Technology Center _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
