Hello, D Haley [2013-11-22 15:38 +0100]: > > Line 42 if configure never ran then there is > > no makefile and make clean fails > I'm not clear about what DEP-8 wants here. DEP8 says > "The currently defined Features are: > no-build-needed The tests can run in an unbuilt tree."
Where are you reading this? This feature doesn't exist, just the inverse exists: "Restrictions: build-needed". > This seems to reverse the build onus, as compared to what you say. > This sentence seems to imply that I have to use the no-build-needed > feature if i want to have an unbuilt tree. No; unless you specify the build-needed restriction the tree won't be built (at least if you properly call adt-run with --no-built-binaries, which is usually what you want in this scenario). > Otherwise a fully built tree should be present - or am I > misunderstanding? If you have some links to relevant discussion > about this, I don't suppose you can post them here? Is this an > ubuntu/debian difference? No, autopkgtest is the same in D/U. > Either way, Ive added a check for the existence of a valid > Makefile, which bypasses make clean as needed [1]. This doesn't > solve the dependency issue however - i've also add the appropriate > Depends. IMHO there is now duplication between control and the > unit-tests control file :(. Right now, yes. There is bug #720458 to address that, I'll look into it in the next weeks. But it's not a very common scenario, so not top-priority. > >Alternatively all the configure/make bits of tests/unittest could be > >replaced > >by the restriction "build-needed" in autopkgtest's control file. > > Unfortunately not. The build *must* occur during the unit test, as > there are different configure flags which enable different code > paths - hence the build at all. So your test builds the .debs and then calls dpkg -i to install them? Please note that this isn't really what autopkgtest is about -- you are supposed to test the packages that are in the *distro*, and their installed version. Running build time is something which your package should do at build time, not in an autopkgtest (even if it involves a multi-build and stuffing the ASSERTified binaries into a -dbg binary package, or just running the upstream tests against them and then throwning them away). If your package already runs the upstream unit tests during package build, then all that the autopkgtest should do is to do some kind of "smoke test" on the installed binaries -- i. e. make sure that you can start the program, and if you can drive it in some batch mode, run it with a small demo input file and ensure it reacts accordingly. This will ensure that all necessary pieces of the package are present, that it hasn't been mis-built, that it has all the necessary dependencies, and so on. > Lastly, there are two versions of the code checked, single-threaded > and openmp multithreaded versions. The unit tests currently check > both, as either failing could be the result of an implementation > error - in the .deb file only the openmp enabled version is present. Then there's little point in having an autopkgtest for the single-threaded version, as it's not being shipped anyway. > 4. > >And finally it seems the 3Depict -t needs a display to run > > Yes, a display server is currently required. Here it works, as I am > running a display server. DEP8 doesn't seem to be clear on what a > minimal environment provides. You can count on nothing else than what you pull in via the test dependencies. The usual approach there is to add xvfb as a test dependency, and start your program/test under "xvfb-run -a". > Just so you know (if you are filing en-masse?) We don't, it's a piece-by-piece analysis/patch/bug filing process. > unfortunately, your links 404/wont resolve (ubuntu-ci is not a valid > hostname?) for me. Right, please ignore the .ubuntu-ci one. The jenkins.qa.ubuntu.com is a public mirror of that and has all the data. Unfortunatel that one is currently down for maintenance as well (should be back up in a few hours). > but I think your description is more than adequate to identify the > issues in this bug without a build log, so I don't specifically need > it. Do you have a schroot or dchroot or something similar? Then you can use adt-virt-schroot/adt-virt-chroot, they are rather convenient and will make sure that you don't forget test dependencies and the like. Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
