Bug#730100: 3depict: autopkgtest fails: missing dependencies, and syntax error

[Martin Pitt]

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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20131122/5f11cb0e/attachment.sig>