On Monday, October 07, 2013 11:42:47 AM Joe MacDonald wrote: > [Re: [libseccomp-discuss] [PATCH 0/3] Install tests for later use] On 13.10.03 (Thu 17:06) Paul Moore wrote: > > On Wednesday, October 02, 2013 08:48:18 PM Joe MacDonald wrote: > > > I'm not sure that there's a huge win or loss either way, though I can > > > certainly see your point of view. > > > > Okay, lets punt on this idea then for the time being. > > > > > As it turns out the whole reason I started down this path is from a > > > packaging point of view. I'm using libseccomp with some Yocto/OE > > > configurations and they've got an infrastructure for doing package > > > regression testing by using the packages' own self-testing. > > > > Can you elaborate a bit more? RPM based packages have a self-test > > mechanism that kicks in during build time and I believe Debian has > > something similar, what does Yocto/OE have? > > It has whatever you like. :-) > > I'm mostly using RPM for my setup, but Yocto can output RPMs, DEBs and IPKs > (it might even support OPK, but I don't think so anymore).
Okay, I need to go check out Yocto a bit more ... > > FWIW, I currently have some patches queued up which will enable a "check" > > target in the top level makefile which will run the regression tests and > > return an error code based on pass/fail. The idea is to make the RPM/Deb > > based package self-tests a bit easier. Once I resolve a few other things > > I'll be pushing these patches to the repository. > > Will this work for a cross-compile environment? Ultimately that's what > I'm trying to accomplish here, having something I can use to test the > ARM packages I build on my x86_64 build system. No, the tests will not currently work in a cross-compiled environment. Aside from running in an ARM VM I don't think that will ever be possible. We do provide tests that verify a number of architectures, but they are still running using the *native* library; I'm not sure if that is what you want or not. Is there any *compiled* binary/library that does offer testing in a cross- compiled environment? I want to know how they do that. > > > Looking at what libseccomp includes, I think it would fit well with > > > that model and help me identify regressions that may either be due to > > > packaging or cross-compilation that I wouldn't be able to (easily) > > > find otherwise. > > > > Are these done at package build time or by an admin during normal runtime? > > Typically these are done at package build time, and in the case of bash, > as I recall it even had a 'check' makefile target that would run them > all on the built source. The intent being that you can test your > newly-built shell before you install it and render /bin/sh inert. > > The way it is used in Yocto, however, is a separate package gets > created (eg. <pkg>-ptest.rpm) and it is then possible to install that on > the target, run the self-tests and remove it using the package > management system. Hmmm, okay, we might be able to do something with that. > > > They're not the sort of thing that would ever be installed by default in > > > any regular build, but something that could be brought in for special > > > case testing and, as in my case, a possible validation step before > > > calling it done. > > > > Hmmm, pointer to more information please. > > Sure thing. https://wiki.yoctoproject.org/wiki/Ptest > > Further to the information at the above link, The test results from > libseccomp aren't in the format required by ptest, but I also didn't > intend to submit any more patches to make them ptest-friendly. The > results are extremely well structured as they are, so my intention was > to process them in my own run-ptest script, included as part of the > recipe, to fit into the required format. Agreed, I'm not sure I want to bother with changing the test output right now, but if the ptest output is well defined, I'm not opposed to including scripts and/or Makefile targets to allow libseccomp to play better with Yocto/ptest. Care to post a RFC patch, or would you rather maintain it privately? > Thanks again, Paul. Let me know if there's anything else I can do. No problem, sorry for such a delay in responding. -- paul moore security and virtualization @ redhat ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk _______________________________________________ libseccomp-discuss mailing list libseccomp-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss
