libquazip binary package has critical bugs

[xtingray]

This is a test made by the Quazip creator:

alqualos@ubuntu:~$ tar xzf quazip-0.6.2.tar.gz
alqualos@ubuntu:~$ cd quazip-0.6.2/
# Rename the source so qztest uses the distribution QuaZIP:

alqualos@ubuntu:~/quazip-0.6.2$ mv quazip quazip-renamed
alqualos@ubuntu:~/quazip-0.6.2$ cd qztest/
alqualos@ubuntu:~/quazip-0.6.2/qztest$ /usr/lib/i386-linux-gnu/qt5/bin/qmake
Project WARNING: CONFIG+=qtestlib is deprecated. Use QT+=testlib instead.

First error (trivial):

alqualos@ubuntu:~/quazip-0.6.2/qztest$ make
# lots of make stuff goes here and ends with this:
.obj/testquazipfile.o: In function `TestQuaZipFile::setFileAttrs()':
testquazipfile.cpp:(.text+0x50ba): undefined reference to `QuaZipNewInfo::setPermissions(QFlags<QFileDevice::Permission>)'
collect2: error: ld returned 1 exit status
make: *** [qztest] Error 1

# The error above is because of a really silly bug in 0.6.2:
# it declares a function, but never defines it.
# In order to get around it, we must edit testquazipfile.cpp
# and comment out the whole body of the last function,
# that is, TestQuaZipFile::setFileAttrs():

alqualos@ubuntu:~/quazip-0.6.2/qztest$ vim testquazipfile.cpp
# editing goes here

Second error (critical):

alqualos@ubuntu:~/quazip-0.6.2/qztest$ make
# Now it compiles OK.
alqualos@ubuntu:~/quazip-0.6.2/qztest$ ./qztest
********* Start testing of TestQuaZip *********
Config: Using QtTest library 5.2.1, Qt 5.2.1
PASS : TestQuaZip::initTestCase()
QFATAL : TestQuaZip::getFileList(simple) Received signal 11
FAIL! : TestQuaZip::getFileList(simple) Received a fatal error.
   Loc: [Unknown file(0)]
Totals: 1 passed, 1 failed, 0 skipped
********* Finished testing of TestQuaZip *********
Aborted (core dumped)

Now, compiling the source code by ourselves works pretty neat:

# Now let's try compiling the sources by ourselves:
alqualos@ubuntu:~/quazip-0.6.2/qztest$ cd ..
alqualos@ubuntu:~/quazip-0.6.2$ mv quazip-renamed quazip
alqualos@ubuntu:~/quazip-0.6.2$ cd quazip/
alqualos@ubuntu:~/quazip-0.6.2/quazip$ /usr/lib/i386-linux-gnu/qt5/bin/qmake
alqualos@ubuntu:~/quazip-0.6.2/quazip$ make
# lots of make stuff

alqualos@ubuntu:~/quazip-0.6.2/quazip$ cd ../qztest/
# Now we should re-link qztest because the library name is different:
# Ubuntu provides libquazip.so.0, while QuaZIP builds by default as libquazip.so.1
# Even better would be to recompile completely, but I've compared the headers,
# and they are exactly identical in Ubuntu and in quazip-0.6.2.tar.gz,
# so re-linking should do the job:

alqualos@ubuntu:~/quazip-0.6.2/qztest$ rm qztest
alqualos@ubuntu:~/quazip-0.6.2/qztest$ make
# link stuff goes here

alqualos@ubuntu:~/quazip-0.6.2/qztest$ env LD_LIBRARY_PATH=../quazip ./qztest
# Now every test passes OK.

So, the problem IS in the libquazip0 binary package!

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: libquazip0 0.6.2-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9
Uname: Linux 3.13.0-24-generic x86_64
ApportVersion: 2.14.1-0ubuntu3
Architecture: amd64
Date: Thu May 8 09:50:52 2014
InstallationDate: Installed on 2014-04-19 (18 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
SourcePackage: libquazip
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Eric Maeker (eric-maeker)]

Please not that libquazip is build using Qt4 as ldd shows

eric@ubuntu:~$ ldd /usr/lib/x86_64-linux-gnu/libquazip.so.0
 linux-vdso.so.1 => (0x00007fffb49f9000)
 libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007feef5ae6000)
 libQtCore.so.4 => /usr/lib/x86_64-linux-gnu/libQtCore.so.4 (0x00007feef5601000)
 libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007feef52fc000)
 libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007feef50e6000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007feef4d20000)
 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007feef4b01000)
 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007feef48fd000)
 libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007feef45f5000)
 librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007feef43ec000)
 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007feef40e6000)
 /lib64/ld-linux-x86-64.so.2 (0x00007feef5f4b000)
 libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007feef3ea7000)

and that you used Qt5.2.1 to build your tests. When you build source+tests with Qt5 all goes fine.

May be this is the source of the problem.

[Eric Maeker (eric-maeker)]

Small test on Ubuntu 14.04

eric@ubuntu:quazip-0.6.2$ sudo apt-get install qt4-qmake libquazip0-dev [add all Qt 4.8* -dev packages]
...

# Building using Qt4.8.x
eric@ubuntu:qztest$ qmake-qt4 qztest.pro
eric@ubuntu:qztest$ make -j4
[No error]

# Testing qztest app
eric@ubuntu:qztest$ ./qztest
[...]
All tests executed successfully

So do you want to Debian package to be build by default with Qt5?

[Sergey Tachenov (laerel)]

Of course that was it! I wonder how I didn't notice it.

I think the package should be built with whatever version of Qt is considered the "main" one for the distro (for example, the one that KDE was linked against). Or, better yet, provide two packages: quazip-qt4 and quazip-qt5. That would certainly eliminate a lot of confusion.

[xtingray (xtingray-gmail)]

Thank you for discovering the cause behind the issue!

About your question: Quazip is some kind of Qt "non-official" module very handy for Qt4 as for Qt5, so the right way to solve this should be providing both versions of the package. I mean: libqt4quazip0-dev and libqt5quazip0-dev

Is this possible?

[Eric Maeker (eric-maeker)]

hummm, why not. The debian/rules can build both of them.
I need to find out how to check what Qt version is the default one on the debian system building the package (in the makefile language may be using qmake -v output), then build qt4/qt5 is just a QMAKE var to change.

Now what should be the best name of the packages? I think that libquazip-qt4, libquazip-qt5 are the best base, no?
Then with the ABI version numbering we should have libquazip1-qtX{-dev}.

As I'm not subscribed to this bug tracking system, please ping me by mail.

Thanks

[Eric Maeker (eric-maeker)]

ah I found where to subscribe forget about the mail

[Sergey Tachenov (laerel)]

The only problem is that the binary should be named differently, should it not? That is, no more libquazip.so.1.0.0 or whatever the version is? Instead, we'll have libquazip-qt4.so.1.0.0 and libquazip-qt5.so.1.0.0. But that would break backwards compatibility. Or did you mean checking "qmake -v" to provide a symlink for the default binary as "libquazip.so.1.0.0"?

I'm seriously thinking about changing target binary names in upstream, though, precisely to avoid this kind of confusion.

[Eric Maeker (eric-maeker)]

Ok, I understand. Please give some time to ask Debian Mentors about the
best configuration for libquazip inside Debian.
I'll ping you as soon as possible

Thanks

[Eric Maeker (eric-maeker)]

Ok, answer is:
- libquazip will link by default to Qt4
- libquazip-qt5 will link to Qt5

I'm in touch with debian mentors to manage the source package as best as possible.
I close this bug.

[Eric Maeker (eric-maeker)]

Debian package have been uploaded to ftp-master. See 0.6.2-2 package.