[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). > 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. > > 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. > > 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. Thanks again, Paul. Let me know if there's anything else I can do. -J. > > > The existing tests include, for example, bash and dbus self-tests, > > both of which I think fall into the same category as you've said the > > libseccomp tests land in, but I could very well be mistaken here as > > I've only really been following along libseccomp development until > > now, not using it much. > -- -Joe MacDonald. :wq
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ 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=60134791&iu=/4140/ostg.clktrk
_______________________________________________ libseccomp-discuss mailing list libseccomp-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss
