[MIR] dcmtk

[Rohan Garg]

Binary package hint: dcmtk

Hi
KOffice now has a new build dep on libdcmtk1-dev and libdcmtk1 which are in universe. We need these libraries moved to main so that KOffice can be built with these dependencies.
I have checked that the package meets all the MIR requirements.

Debian Packages are maintained and can be easily sync'd or merged as per requirements, all dependencies are in main and i could find no security issues with the source package.It does not have any binaries which need to be installed to /sbin, /usr/sbin nor any daemons.

Debian Packages :
http://packages.debian.org/search?keywords=libdcmtk1
http://packages.debian.org/search?keywords=libdcmtk1-dev

[Didier Roche-Tolomelli (didrocks)]

All point checked and sounds a good candidate for Main.

However, I have some build issue trying to rebuilding the tests:
c++ -DHAVE_CONFIG_H -DNDEBUG -c -I. -I. -I../include -I../../config/include \
   -O -I/usr/include/libxml2 -D_REENTRANT -D_XOPEN_SOURCE_EXTENDED -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_BSD_COMPAT -D_OSF_SOURCE -D_POSIX_C_SOURCE=199506L -g -O2 ofconfig.cc
ar cruv libofstd.a oflist.o ofstring.o ofcmdln.o ofconapp.o offname.o ofconsol.o ofthread.o oflogfil.o ofcond.o ofstd.o ofcrc32.o ofdate.o oftime.o ofdatime.o ofconfig.o
a - oflist.o
a - ofstring.o
a - ofcmdln.o
a - ofconapp.o
a - offname.o
a - ofconsol.o
a - ofthread.o
a - oflogfil.o
a - ofcond.o
a - ofstd.o
a - ofcrc32.o
a - ofdate.o
a - oftime.o
a - ofdatime.o
a - ofconfig.o
ranlib libofstd.a
make[3]: quittant le répertoire « /home/didrocks/sandbox/dcmtk-3.5.4/ofstd/libsrc »
(cd tests; /usr/bin/make ARCH="" all)
make[3]: entrant dans le répertoire « /home/didrocks/sandbox/dcmtk-3.5.4/ofstd/tests »
c++ -DHAVE_CONFIG_H -DNDEBUG -c -I. -I. -I../include -I../../config/include -I../include \
   -O -I/usr/include/libxml2 -D_REENTRANT -D_XOPEN_SOURCE_EXTENDED -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_BSD_COMPAT -D_OSF_SOURCE -D_POSIX_C_SOURCE=199506L -g -O2 tststack.cc
c++ -O -I/usr/include/libxml2 -D_REENTRANT -D_XOPEN_SOURCE_EXTENDED -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_BSD_COMPAT -D_OSF_SOURCE -D_POSIX_C_SOURCE=199506L -g -O2 -Wl,-Bsymbolic-functions -L../libsrc -o tststack tststack.o -lofstd -lrt -lpthread -lnsl
../libsrc/libofstd.so: undefined reference to `sem_init'
../libsrc/libofstd.so: undefined reference to `pthread_mutex_trylock'
../libsrc/libofstd.so: undefined reference to `pthread_rwlock_trywrlock'
../libsrc/libofstd.so: undefined reference to `pthread_key_create'
../libsrc/libofstd.so: undefined reference to `pthread_rwlock_rdlock'
../libsrc/libofstd.so: undefined reference to `pthread_rwlock_tryrdlock'
../libsrc/libofstd.so: undefined reference to `sem_destroy'
../libsrc/libofstd.so: undefined reference to `pthread_getspecific'
../libsrc/libofstd.so: undefined reference to `pthread_rwlock_wrlock'
../libsrc/libofstd.so: undefined reference to `pthread_create'
../libsrc/libofstd.so: undefined reference to `pthread_rwlock_destroy'
../libsrc/libofstd.so: undefined reference to `pthread_rwlock_init'
../libsrc/libofstd.so: undefined reference to `pthread_rwlock_unlock'
../libsrc/libofstd.so: undefined reference to `sem_post'
../libsrc/libofstd.so: undefined reference to `sem_trywait'
../libsrc/libofstd.so: undefined reference to `pthread_setspecific'
../libsrc/libofstd.so: undefined reference to `sem_wait'
../libsrc/libofstd.so: undefined reference to `pthread_join'
collect2: ld returned 1 exit status
make[3]: *** [tststack] Erreur 1
make[3]: quittant le répertoire « /home/didrocks/sandbox/dcmtk-3.5.4/ofstd/tests »

I think that should be related to the new DSO linking policy (http://wiki.debian.org/ToolChain/DSOLinking). Can you please have a look at it?

It would be nice if someone in the team subscribe to the bug report (and it seems to be a very _low_ traffic).
Keeping in sync with debian sounds the best option fixing those issues.

(note: 3.6.0 is just out for ...

[Matthias Klose (doko)]

libofstd.so needs to be linked with -lpthread

[Rohan Garg (rohangarg)]

I can still produce the linking issue with the new 3.6 release ( Ported over from debian ), here's the complete build log : http://paste.kde.org/4341/

[Rohan Garg (rohangarg)]

New 3.6.0 Packages can be found here : https://launchpad.net/~rohangarg/+archive/experimental/+packages

[Kees Cook (kees)]

I'm not a fan of adding this library to main because it seems to reimplement a large set of interfaces that already have so many other libraries implementing them, and additionally has embedded code copies, like a number of image processing bits (libjpeg), etc. I would at least want this built again libjpeg instead of using an internal copy first.

[Rohan Garg (rohangarg)]

Hi
dcmtk already builds against libjpeg62-dev, or are you talking about libjpeg8-dev?

[Kees Cook (kees)]

I mean at least these:

dcmjpeg/libijg8
dcmjpeg/libijg12
dcmjpeg/libijg16

And the resulting shipped libraries:

-rw-r--r-- root/root 170528 2011-02-14 15:06 ./usr/lib/libijg8.so.2.0.0
-rw-r--r-- root/root 170528 2011-02-14 15:06 ./usr/lib/libijg12.so.2.0.0
-rw-r--r-- root/root 170528 2011-02-14 15:06 ./usr/lib/libijg16.so.2.0.0

[Matthias Klose (doko)]

the upstream build system, or what the debian maintainer make out of it, is just ugly.

[Matthias Klose (doko)]

so no, please don't promote this to main until the package has to be built three times in a row.

[Matthias Klose (doko)]

the build with ld --as-needed is not fixed, just turned off :-/

[Rohan Garg (rohangarg)]

Hi
Small update, KOffice saw a fork and thus is no longer required, instead Calligra will be superseeding KOffice soon in our archives, i think we can close this bug for now.

[Matthias Klose (doko)]

so the end of the story is that you did break some stuff like lipsia and odin, and then it was just for fun ... hurray \o/

[Rohan Garg (rohangarg)]

I'm extremely sorry for any inconvenience this has caused, i had no idea KOffice would be forked soon and we would be dealing with Calligra and that we won't be require dcmtk, yet again, I am sorry and i apologize.

[Colin Watson (cjwatson)]

calligra still seems to build-depend on libdcmtk2-dev. What's going on here?

[Felix Geyer (debfx)]

calligra has been fixed to drop the build-dependency, so closing this now.