Multi-value test failing under Fedora

[verdammelt]

@dtimms reports:

Just a note that attempting: make check is showing a test failure in:

FAIL: multi-value-attribute.test

Testsuite summary for tnef 1.4.11
============================================================================
# TOTAL: 13
# PASS:  12
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See tests/files/test-suite.log

Given this issue relates to improvements for mult-value fields, this might be related to these patches.

[verdammelt]

reference comments in #3

[ileGITimo]

If I

• clone 1.4.11 with git on my Fedora 20 system
• rename configure.in to configure.ac

then run

• aclocal; autoheader; autoconf; automake
• ./configure
• make all
• make check

Everything works fine, no errors, all tests pass:

============================================================================
Testsuite summary for tnef 1.4.11
============================================================================
# TOTAL: 13
# PASS:  13
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================

[dtimms]

Firstly, I assumed that the source archive on sf.net would be 100% identical to that on github:

ls -l
-rw-rw-r--. 1 davidt davidt 4570802 Aug  8 19:46 tnef-1.4.11.git.tar.gz
-rw-rw-r--. 1 davidt davidt 3978941 Aug  8 19:47 tnef-1.4.11.sf.net.tar.gz

ie the archives are different by about 570kB. So, perhaps the sf.net archive is missing the needed test files...build using sf.net archive:

PASS: garbage-at-end.test
FAIL: multi-value-attribute.test
make[6]: Entering directory `/home/davidt/rpmbuild/BUILD/tnef-1.4.11/tests/files'
...
============================================================================
Testsuite summary for tnef 1.4.11
============================================================================
# TOTAL: 13
# PASS:  12
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

Possible resolution: update sf.net with the file from github. However, building with that gives a much earlier error:

/var/tmp/rpm-tmp.aIwt5n: line 40: ./configure: No such file or directory

So ./configure is not included in the source archive from github, but it is in the source archive from sourceforge.net. Is that an oversight ? Meanwhile: one way is to run autoconf to generate ./configure:

+ autoconf
configure.ac:4: error: possibly undefined macro: AM_INIT_AUTOMAKE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:47: error: possibly undefined macro: AM_MAINTAINER_MODE
configure.ac:50: error: possibly undefined macro: AC_COMPILE_WARNINGS
configure.ac:53: error: possibly undefined macro: AC_DEBUG_COMPILE
error: Bad exit status from /var/tmp/rpm-tmp.1gv1Ua (%build)

For Fedora 20:

$ autoconf --version
autoconf (GNU Autoconf) 2.69
$ autoreconf --version
autoreconf (GNU Autoconf) 2.69
$ automake --version
automake (GNU automake) 1.13.4

OK, try autoreconf before ./configure ... succeeds. rpmbuild suceeds.

I'm guessing ileGITimo's [aclocal; autoheader; autoconf; automake] achieves the same thing. I tried just autoconf, then autoheader, then aclocal when trying a manual build. It seemed to require all 4 before it could successfully create configure, and build.

From what I can understand usually the ./configure would be created by the upstream developer, and included in the source archive. Has it simply been missed ? Or does the build instructions need to add the autoreconf step ?

[ileGITimo]

Mark moved tnef from sf.net to gihub. If you go to sf.net you should see the deprecation notice.

The instructions on my post fix the problems you list. I just forked the project and sent a pull request with the configure.in name change and updated README and INSTALL to add autoreconf to the build instructions.

Man autoreconf does start with: Run autoconf' (andautoheader', aclocal',automake', autopoint' (formerlygettextize'), and `libtoolize' where appropriate) repeatedly to remake the GNU Build System file.

[verdammelt]

@dtimms @ileGITimo

GitHub provides it's own tarball - which is just a tar of the repo (without .git files). SourceForge tarballs were created by me via the dist Makefile target. Thus there is a difference between the two.

However it sounds like in this case I created the SourceForge tarball incorrectly. I may have forgotten to update a list of files to include. I'll investigate that.

Going forward I don't think I'll create anymore SourceForge tarballs - merely continue to announce tnef releases there.

I personally use autoreconf as a means of doing the whole autoconf dance until ./configure is created.

Thanks to you both for your research into what seems to be going wrong here. I will see if the SourceForge tarball can be corrected.

[verdammelt]

Problem was easily reproduced by building from the tarball that was generated for SourceForge.

[verdammelt]

@dtimms @ileGITimo What is your opinion of getting rid of tarball distributions entirely? I don't mean the github archive of the repository (looks like the same as git export) but the distribution created by make dist. This archives up the results from acreconf (or equivalent) so that the user just needs to ./configure && make.

Do you think anyone still uses those distribution tarballs anymore?

[ileGITimo]

@dtimms will be packaging this as an rpm for Fedora so he will have a more definitive answer, but I believe the src rpm does include the sources as a tar file, plus a few patches to be applied to make Fedora specific changes.

[dtimms]

Sorry, missed the query above. In any rate, I prefer to make it less work to keep the package up to date. I guess it's better to have a release build of the source, but if the tools don't handle that, then we can make do with the raw git source. One thing about packaging is that the machine that builds the package is very independent of the machine that will run the final package, so any tricks like autoreconf shouldn't assume things (eg cpu capability by examining the build machine). Seems the archive is larger without the un-needed parts removed (4.7 was 4.0 MB), or maybe that's the missed test/check file.

However, it does build OK with the extra autoreconf line, (and I think one of the doc file is left as a .in, rather than the final output file). In the package I just matched the new time, to get the package build to succeed. @ileGITimo: Would you have a chance to test the tnef builds I did last week for Fedora, and comment on the Bodhi system, thanks: yum --enablerepo=updates-testing update tnef* https://admin.fedoraproject.org/updates/search/tnef and then choose tnef-1.4.12-1.fc?? It works OK with the few ms mail attachments my family send me, but be great to have a bit wider testing.

[ileGITimo]

I only use tnef to decode voice mail messages that get to my linux box pushed from outlook/exchange. I'll try calling myself when I get to work and try it out. I'll tick Bodhi if it works...