Heimdal 7.5.0: Some tests are run even if feature is disabled and test not possible

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Heimdal 7.5.0: Some tests are run even if feature is disabled and test not possible

Harald Barth-2

I did configure with --disable-digest (I thought why would I need NTLM related stuff).

Looks to me that the tests are not disabled when the feature is disabled.

../heimdal-7.5.0/configure --with-libintl --prefix=/usr/heimdal-7.5.0 --disable-kcm --with-openssl --disable-otp --enable-pthread-support --with-readline --disable-digest --with-ipv6 --enable-kx509 --without-openldap --enable-pk-init --with-x --localstatedir=/var --disable-silent-rules --disable-ndbm-db --enable-lmdb-db --enable-mdb-db

From the test output:

(...)
Getting digestserver initial tickets
======context building for each mech
ntlm
lt-test_context: accept_sec_context: gss-code: 851968  Miscellaneous failure (see text) -- mech-code: 0 unknown mech-code 0 for mech unknown
test failed
(...)

In total 2 tests fail (easy to reproduce)

When I do a --enable-digest instead, the tests pass.

Yes, the information what the different enable-xxx and with-xxx flags
do is a little sparse.

Happy new year,
Harald.

Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 7.5.0: Some tests are run even if feature is disabled and test not possible

Andrew Bartlett
On Tue, 2019-01-08 at 13:20 +0100, Harald Barth wrote:
> I did configure with --disable-digest (I thought why would I need
> NTLM related stuff).
>
> Looks to me that the tests are not disabled when the feature is
> disabled.

I would caution from bad experiences in samba that making tests
optional risks missing the tests entirely.

We have found important tests were always skipped because the name
being tested for in the test code didn't match the name the build
system was using (we were doing a grep in config.h for HAVE_XXX).  

So I'm just passing on a warning that such a feature is not risk-free.

Andrew Bartlett

--
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba



Reply | Threaded
Open this post in threaded view
|

Generated files in source tree: kadm5-protos.h kadm5-private.h

Harald Barth-2
In reply to this post by Harald Barth-2

When I build heimdal I normally have seperate source and build trees.

Then there are the files kadm5-protos.h kadm5-private.h which come
with the tar ball, live in source-tree/lib/kadm5, are obviously
generated and when other files in lib/kadm5 are touched are rebuild
with a perl script.

I very much dislike how this is done currently.

I suggest the following improvements:

* If one really feels the urge to distribute generated files with the
  tar ball, do cp -p them over to the build tree.

* If you need to regen the files with a perl script, write only to the
  build tree.

* If the regen perl scripts fails, throw an error, don't just continue
  with the make like nothing happened.

* If the regen perl script must have odd dependencies like libjson-perl,
  somehow throw a reasonable error if that's not available.


Have a look at the cf/make-proto.pl it looks very unfinished to me.

* $Id$ should have a value or be removed

* A Copyright notice should be there

* Some better error handling than die "foo" would be nice

* I think this "Makefile obfuscation" does not work as
  intened because if $(srcdir)/$$f is missing because
  the perl step above failed, this will not be noticed.

        for f in $$foo; do \
                f=`basename $$f`; \
                if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
                else file="$$f"; fi; \
                if cmp -s  $$file $(buildkadm5include)/$$f 2> /dev/null ; then \
                : ; else \
                        echo "cp $$file $(buildkadm5include)/$$f";\
                        cp $$file $(buildkadm5include)/$$f; \
                fi ; \
        done


I'd like to see that the build process of the kadmin stuff uses
kadm-protos.h from buildtree/include/kadm5/ and that gets built from
either the source files by make-proto.pl or if all the source files
are older from a distributed copy of kadm5-protos.h As it is now,
you can end up with a buildtree/include/kadm/kadm5-protos.h that is
inaccurate and/or older than soucretree/lib/kadm5/kadm5-protos.h.

I can not find any place where the make-proto.pl is used together with
the -x option. What is it supposed to do. Can you find what the -x
does?

If the -x is not used, the JSON dependency can be removed completely.

If I sound a bit miffed this can be attributed to what I thought would
be a completely unrelated 10 min change/recompile/test cycle ended up
to be yak shaving galore expericence which took several hours. Don't
get me wrong, I know this is "free software" but I'm unhappy in the
same way one would not be happy if "free beer" would contain some
extra ingrediences which do not belong in beer in the first place ;-)

Harald.

Reply | Threaded
Open this post in threaded view
|

Re: Generated files in source tree: kadm5-protos.h kadm5-private.h

Jeffrey Altman-2
On 3/21/2019 6:45 AM, Harald Barth wrote:
> [...]
> If I sound a bit miffed this can be attributed to what I thought would
> be a completely unrelated 10 min change/recompile/test cycle ended up
> to be yak shaving galore expericence which took several hours. Don't
> get me wrong, I know this is "free software" but I'm unhappy in the
> same way one would not be happy if "free beer" would contain some
> extra ingrediences which do not belong in beer in the first place ;-)

As a reminder, none of the active contributors to Heimdal work for
Heimdal.  Those that are employed by AuriStor and Two Sigma work on
Heimdal in sprints.  At least in the case of myself and AuriStor funded
developers, our work on Heimdal is primarily intended to satisfy the
requirements of AuriStor's internal use and its customers.

Over the months you have posted many requests for bug fixes and feature
changes to this mailing list.  To increase the likelihood that someone
will review your request and do something about it, I suggest that you
submit it either as a GitHub Issue

  https://github.com/heimdal/heimdal/issues

or as a Pull Request

  https://github.com/heimdal/heimdal/pulls

During a future sprint I or other contributors can evaluate it, respond
to it and set a milestone if appropriate.

To be completely honest, I do not review the history of this mailing
list when I have time to work on Heimdal.  There is already more than
enough queued in GitHub for the Heimdal 8 release.  Please help us help
you by filing requests in GitHub.  I for one do not have cycles to spare
to copy reports from this mailing list into GitHub.

Jeffrey Altman



smime.p7s (5K) Download Attachment