Bug 573910 - (dcmtk) Review Request: dcmtk - Offis DICOM Toolkit
Review Request: dcmtk - Offis DICOM Toolkit
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Lemenkov
Fedora Extras Quality Assurance
:
Depends On:
Blocks: vxl amide
  Show dependency treegraph
 
Reported: 2010-03-16 01:45 EDT by Andreas Loening
Modified: 2011-09-18 14:22 EDT (History)
5 users (show)

See Also:
Fixed In Version: dcmtk-3.6.0-5.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-04-26 12:26:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
lemenkov: fedora‑review+
tibbs: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Andreas Loening 2010-03-16 01:45:03 EDT
Spec URL: http://www.stanford.edu/~loening/fedora/dcmtk.spec
SRPM URL: http://www.stanford.edu/~loening/fedora/dcmtk-3.5.4-3.fc12.src.rpm

Description: Please note, this is my first package, and as such I guess I'll need a sponsor. Also, if you have a suggestion for a more appropriate "Group" field, let me know.

DCMTK is a collection of libraries and applications implementing large parts 
the DICOM standard. It includes software for examining, constructing and 
converting DICOM image files, handling offline media, sending and receiving 
images over a network connection, as well as demonstrative image storage 
and worklist servers. DCMTK is is written in a mixture of ANSI C and C++. 
It comes in complete source code and is made available as "open source" 
software.

Install DCMTK if you are working with DICOM format medical image files.
Comment 1 Mario Ceresa 2010-03-16 06:13:05 EDT
Hello Andreas,
thanks for your submission! Having dcmtk in Fedora is of great interest as it means that we can use it as both a server to receive and store DICOM medical images, and as a client to process them. Many software in the medical field make use of the dicom standard.

I'm not a sponsor myself, so I cannot directly approve your first package, but I'll try to help ease the process as far as I can:

-) I added the FE-NEEDSPONSOR and FE-SCITECH blockers so sponsor and people who work on the Tech SIG would see the request faster.

-) I added the package to the Medical SIG too, at https://fedoraproject.org/wiki/SIGs/FedoraMedical

-) I put a blocker to the VXL package too, as we will require dcmtk.

I'm working on the package review and I'll post it soon.

Thanks,

Mario
Comment 2 Mario Ceresa 2010-03-16 15:17:30 EDT
Hello Andreas!

there was a lot of output from the rpmlist command with your srpm.

I reworked it a little bit:

1) Changed license to BSD
2) Changed group (we can change it again if you like)
3) Removed requires as rpm should pick them up automatically
4) Added BR: dos2unix as one files needs to be converted to unix
5) Removed Requires from devel subpackage for the same reason
6) Removes --prefix=/usr as it seems to me not necessary
7) tried to enable parallel make (-j ) but the build fails, so restored the original value
8) etc should not be a sub dir of /usr
9) moved all conf files to /etc/dcmtk
10) move arch-indipendent files to /usr/share/dcmtk
11) moved all doc to the proper subdir (I'm not sure if there is a more elegant way: I tired fiddling for a while with %doc macro but at last I gave up)
12) converted ciphers.txt to unix format
13) Added ownership of doc dir and files
14) added ownership of /etc/dcmtk and files
15) added ownership of /usr/share/dcmtk and files
16) changed changelog release format to comply with rpmlint

Here follows a complete diff:
--- dcmtk.spec.orig     2010-03-16 06:38:38.000000000 +0100
+++ dcmtk.spec  2010-03-16 19:41:49.000000000 +0100
@@ -2,20 +2,14 @@
 Summary: Offis DICOM Toolkit (DCMTK)
 Version: 3.5.4
 Release: 3%{?dist}
-License: BSD(ish)
-Group: Applications/Multimedia
+License: BSD
+Group: Development/Libraries
 Source:  ftp://dicom.offis.de/pub/dicom/offis/software/dcmtk/dcmtk354/%{name}-%{version}.tar.gz
 Patch1: dcmtk-3.5.4_shared.patch
 Patch2: dcmtk-3.5.4_tlslayer.patch
 URL: http://dicom.offis.de/dcmtk.php.en
 BuildRoot: %{_tmppath}/%{name}-%{version}-root
-Requires: libjpeg
-Requires: libpng
-Requires: libtiff
-Requires: libxml2
-Requires: openssl
-Requires: tcp_wrappers
-Requires: zlib
+
 BuildRequires: libjpeg-devel
 BuildRequires: libpng-devel
 BuildRequires: libtiff-devel
@@ -23,6 +17,7 @@
 BuildRequires: openssl-devel
 BuildRequires: tcp_wrappers-devel
 BuildRequires: zlib-devel
+BuildRequires: dos2unix
 
 %description
 DCMTK is a collection of libraries and applications implementing large parts 
@@ -39,46 +34,62 @@
 Summary: Development Libraries and Headers for dcmtk
 Group: Development/Libraries
 Requires: %{name} = %{version}-%{release}
-Requires: libjpeg-devel
-Requires: libpng-devel
-Requires: libtiff-devel
-Requires: libxml2-devel
-Requires: openssl-devel
-Requires: tcp_wrappers-devel
-Requires: zlib-devel
 
 %description devel
 Development Libraries and Headers for dcmtk.  You only need to install
 this if you are developing programs that use the dcmtk libraries.
 
-
 %prep
 %setup -q
 %patch1 -p1
 %patch2 -p1
 
 %build
-%configure --prefix=/usr
+%configure
 make
 
 %install
 rm -rf $RPM_BUILD_ROOT
 make install DESTDIR=$RPM_BUILD_ROOT
 make install-lib DESTDIR=$RPM_BUILD_ROOT
-mv $RPM_BUILD_ROOT/etc $RPM_BUILD_ROOT/usr/etc
-mkdir $RPM_BUILD_ROOT/usr/share/dcmtk
-mv $RPM_BUILD_ROOT/usr/%{_lib}/dicom.dic $RPM_BUILD_ROOT/usr/share/dcmtk/
+
+#Move configuration file from /etc to /etc/dcmtk/
+mkdir $RPM_BUILD_ROOT/etc/%{name}
+mv $RPM_BUILD_ROOT/etc/*.cfg $RPM_BUILD_ROOT/etc/%{name}/
+
+#Move arch indipendent data to /usr/share/dcmtk
+mkdir $RPM_BUILD_ROOT/usr/share/%{name}
+mv $RPM_BUILD_ROOT/usr/share/data $RPM_BUILD_ROOT/usr/share/%{name}/
+
+#Move doc files from /usr/share/doc to /usr/share/doc/dcmtk/
+mkdir $RPM_BUILD_ROOT/usr/share/doc/%{name}-%{version}/
+mv $RPM_BUILD_ROOT/usr/share/doc/*.txt $RPM_BUILD_ROOT/usr/share/doc/%{name}-%{version}/
+mv $RPM_BUILD_ROOT/usr/share/doc/COPYRIGHT $RPM_BUILD_ROOT/usr/share/doc/%{name}-%{version}/
+mv $RPM_BUILD_ROOT/usr/share/doc/FAQ $RPM_BUILD_ROOT/usr/share/doc/%{name}-%{version}/
+mv $RPM_BUILD_ROOT/usr/share/doc/HISTORY $RPM_BUILD_ROOT/usr/share/doc/%{name}-%{version}/
+
+mv $RPM_BUILD_ROOT/usr/%{_lib}/dicom.dic $RPM_BUILD_ROOT/usr/share/%{name}/
+
+mkdir -p %{buildroot}/usr/%{_lib}/%{name}/
+mv %{buildroot}/usr/%{_lib}/*.so* %{buildroot}/usr/%{_lib}/%{name}/
+
+dos2unix %{buildroot}%{_docdir}/%{name}-%{version}/ciphers.txt
 
 %clean
 rm -rf $RPM_BUILD_ROOT
 
 %files
 %defattr(-,root,root)
-%doc COPYRIGHT README
+%dir %{_docdir}/%{name}-%{version}
+%{_docdir}/%{name}-%{version}/*
+%dir %{_sysconfdir}/%{name}
+%{_sysconfdir}/%{name}/*
+%dir %{_datadir}/%{name}
+%{_datadir}/%{name}/*
+
 %{_bindir}/*
 %{_libdir}/*
-%{_prefix}/etc/*
-%{_datadir}/*
+%{_mandir}/man1/*
 
 %files devel
 %defattr(-,root,root)
@@ -88,13 +99,13 @@
 %postun -p /sbin/ldconfig
 
 %changelog
-* Mon Mar 15 2010 Andy Loening <loening@alum dot mit dot edu> -3.54-3
+* Mon Mar 15 2010 Andy Loening <loening@alum dot mit dot edu> 3.5.4-3
 - updates for packaging with fedora core
 
-* Sat Jan 02 2010 Andy Loening <loening@ alum dot mit dot edu> -3.54-2
+* Sat Jan 02 2010 Andy Loening <loening@ alum dot mit dot edu> 3.5.4-2
 - tlslayer.cc patch for openssl 1.0 
 
-* Thu Feb 02 2006 Andy Loening <loening @ alum dot mit dot edu> - 3.54-1
+* Thu Feb 02 2006 Andy Loening <loening @ alum dot mit dot edu> 3.5.4-1
 - initial build


Still we have some problems:

[makerpms@shadow rpmbuild]$ rpmlint SPECS/dcmtk.spec SRPMS/dcmtk-3.5.4-3.fc12.src.rpm RPMS/i686/dcmtk-3.5.4-3.fc12.i686.rpm RPMS/i686/dcmtk-devel-3.5.4-3.fc12.i686.rpm 
dcmtk.src: W: spelling-error Summary(en_US) Offis -> Offs, Offish, Off is
dcmtk.src: W: spelling-error %description -l en_US worklist -> work list, work-list, workload
dcmtk.i686: W: spelling-error Summary(en_US) Offis -> Offs, Offish, Off is
dcmtk.i686: W: spelling-error %description -l en_US worklist -> work list, work-list, workload
dcmtk.i686: W: unstripped-binary-or-object /usr/lib/dcmtk/libdcmdsig.so
dcmtk.i686: W: unstripped-binary-or-object /usr/lib/dcmtk/libdcmnet.so
dcmtk.i686: W: unstripped-binary-or-object /usr/lib/dcmtk/libdcmjpeg.so
dcmtk.i686: W: unstripped-binary-or-object /usr/lib/dcmtk/libofstd.so
dcmtk.i686: W: unstripped-binary-or-object /usr/lib/dcmtk/libdcmtls.so
dcmtk.i686: W: unstripped-binary-or-object /usr/lib/dcmtk/libdcmimage.so
dcmtk.i686: W: unstripped-binary-or-object /usr/lib/dcmtk/libdcmwlm.so
dcmtk.i686: W: unstripped-binary-or-object /usr/lib/dcmtk/libdcmsr.so
dcmtk.i686: W: unstripped-binary-or-object /usr/lib/dcmtk/libijg12.so
dcmtk.i686: W: unstripped-binary-or-object /usr/lib/dcmtk/libdcmdata.so
dcmtk.i686: W: unstripped-binary-or-object /usr/lib/dcmtk/libdcmimgle.so
dcmtk.i686: W: unstripped-binary-or-object /usr/lib/dcmtk/libdcmpstat.so
dcmtk.i686: W: unstripped-binary-or-object /usr/lib/dcmtk/libijg16.so
dcmtk.i686: W: unstripped-binary-or-object /usr/lib/dcmtk/libijg8.so
dcmtk.i686: W: unstripped-binary-or-object /usr/lib/dcmtk/libdcmqrdb.so
dcmtk.i686: W: file-not-utf8 /usr/share/doc/dcmtk-3.5.4/ciphers.txt
dcmtk.i686: W: wrong-file-end-of-line-encoding /usr/share/doc/dcmtk-3.5.4/randseed.txt
dcmtk.i686: W: non-conffile-in-etc /etc/dcmtk/storescu.cfg
dcmtk.i686: W: non-conffile-in-etc /etc/dcmtk/storescp.cfg
dcmtk.i686: W: non-conffile-in-etc /etc/dcmtk/printers.cfg
dcmtk.i686: W: non-conffile-in-etc /etc/dcmtk/dcmqrscp.cfg
dcmtk.i686: W: non-conffile-in-etc /etc/dcmtk/dcmpstat.cfg
dcmtk-devel.i686: W: no-documentation

The most serious seem to me the one regarding the shared libs: we really need to have the linker generate a proper soname before that we can package dcmtk, but I don't have a clue on where to set the magic option in autoconf (I use cmake only). I'll investigate further.

Please comment on these changes I made and, if you find them worth, include them in your srpms, post an updated version and I'll continue with the review.
I'm still learning to make a proper review so don't be afraid to tell me if you think that I made a change by mistake!

If you haven't already, you might also want to read:
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group

I hope that you'll get sponsored soon and that we'll find a quick way to solve all the issue so we all can enjoy dcmtk in Fedora!

Thanks for your contribution and your patience,

Mario
Comment 3 Per Inge Mathisen 2010-05-06 05:45:57 EDT
Thanks a lot for taking the effort to put DCMTK in Fedora!

Please compile with --with-private-tags so that the private tag file is included, it makes life with dcmdump much easier.

Also, dcmtk-3.5.4 is really old and has several known issues that can be rather problematic. I have collected fixes for several of them at https://gna.org/projects/pdcmtk/ (patched dcmtk). I'd encourage you to include patches for some of the more serious issues (especially the --key parameter bug).
Comment 4 Andreas Loening 2010-06-14 20:22:10 EDT
Hi Mario.

Sorry for the extremely slow response.

I took most of your suggestions and added them to the SPEC file.

A couple things.
1) I left the generated libraries in /usr/lib, it looks like one of your additions was trying to move them into /usr/lib/dcmtk. Any particular reason to do this?

2) Regarding your suggestions #13-15, I didn't understand what you were trying to accomplish with these changes.

Regarding getting proper sonames for the libraries... not sure how to do that easily. DCMTK doesn't use libtool, so they're not autogenerated. Converting DCMTK to libtool would be a major undertaking. It it valid to just use some shell scripting to rename the current library.so files to library.so.3.5.4 and generate the appropriate symbolic links?

Also, should the libraries be stripped... and if so, how does one generate the correct information to make a relevant dcmtk-libs-debuginfo rpm?

Andy
Comment 5 Andreas Loening 2010-06-14 20:26:07 EDT
Hi Per,

I've added the --with-private-tags to the shell script.

I took a quick look at the differences between dcmtk-3.5.4 and pdcmtk. I'm a bit reluctant to just apply all the differences, as I'm not sure which are bug-fixes (great!), which ones are simple add-ons (ok), and which ones would change behaviour from dcmtk-3.5.4 (bad).

Any comments?

And yeah, 3.5.4 is really old... maybe we should be packaging a pre-release version of 3.5.5 instead?
Comment 6 Per Inge Mathisen 2010-06-15 03:43:54 EDT
Hi. Good to see this ball rolling again :)

pdcmtk contains only one add-on (the new storescp placeholder fields added in r18 and r24), and only one piece of changed behaviour (r45).

Concerning r45, this adds a patch that fixes problem with meta header information not being read correctly when the meta header is malformed (incorrect size). This is a recurrent problem with the GE SIGNA HDx CT scanner.

You can easily and safely back out these three changes, and use the remainder, which are only isolated bug fixes. I recommend reading the full commit history - it is not long. If you want, I can roll a patch for you against plain dcmtk-3.5.4 with whatever fixes you think should be included.

As regards the development ("3.5.5") version, I personally think it is too much a work in progress at the moment to recommend it for production use.
Comment 7 Andreas Loening 2010-06-27 18:01:16 EDT
Hi Per,

I ended up incorporating almost everything with the following exceptions:

1) did not include the change to tlslayer.cc as I already included a patch based on the dcmtk 3.5.5 development branch

2) did not include the pdcmtk spec file

3) did not include the changes to configuration files - getting things placed in the right positions in the directory tree is handled by the spec file
Comment 8 Andreas Loening 2010-06-27 18:04:59 EDT
Hi Mario,

I put a new version of the SPEC file and associated RPM's up at:
      http://www.stanford.edu/~loening/fedora/

Debuginfo now is built correctly.

The only remaining issue... I think... is the lack of soname's with the generated library. Do you know if this is a real blocker?
Comment 9 Mario Ceresa 2010-06-28 04:40:42 EDT
(In reply to comment #8)
> Hi Mario,
> 
> I put a new version of the SPEC file and associated RPM's up at:
>       http://www.stanford.edu/~loening/fedora/
> 
> Debuginfo now is built correctly.
> 
> The only remaining issue... I think... is the lack of soname's with the
> generated library. Do you know if this is a real blocker?    

Hello Andreas! that's great to see so much work on dcmtk: thank you and Per so much for your efforts on this package.

I'll talk with Peter, my sponsor, regarding the soname's problem and we'll try to find a solution soon!

Best regards,

Mario
Comment 10 Mario Ceresa 2010-09-18 12:07:13 EDT
Hello! here there is my initial cut: adapting a patch from 

https://bugzilla.redhat.com/attachment.cgi?id=335402&action=diff

I prepared the following patch and spec:
http://mrceresa.fedorapeople.org/dcmtk-3.5.4_add_soname.patch
http://mrceresa.fedorapeople.org/dcmtk.spec

which seem to generate correctly the shared lib *BUT* I have errors in linking the applications to those newly generated lib. (undefined references)

I'm surely missing something and go on investigating, but if someone has any idea please share :)
Comment 11 Peter Lemenkov 2010-11-12 07:55:43 EST
I'll review it. Andreas, are you still interested in packaging this or will you hand over it to Mario?
Comment 12 Andreas Loening 2010-11-17 01:06:18 EST
Hi Peter,

I've had precious little time to devote to side projects, so if Mario would be interested in being the lead on the packaging that'd be quite okay with me.

Mario, did you ever get the soname issue worked out?
Comment 13 Mario Ceresa 2010-11-19 18:59:29 EST
Hello Andreas,

Ok I'll step in! In the new srpm to put the soname I remove:

$(library): $(objs)
	$(AR) $(ARFLAGS) $@ $(objs)
	$(RANLIB) $@

 from the Makefile of the libs  and add

$(library): $(objs)
	soname=`basename $@`.0 ; \
	$(CC) -shared -o $@.tmp \
		-Wl,--whole-archive,$<,--no-whole-archive \
		-Wl,--soname,$$soname,-z,-defs $(objs)
	if readelf -d $@.tmp | fgrep -q TEXTREL; then exit 1; fi
	mv $@.tmp $@ ; ln $@ $@.0

but the produced libs lacks some symbols and the linking of further files fails.
Unfortunately my knowledge of autotools is so poor that I don't really know where to go on from know...

Any ideas?

Mario
Comment 14 Mario Ceresa 2010-11-19 19:06:53 EST
The most updated srpms is here:

http://mrceresa.fedorapeople.org/dcmtk-3.5.4-4.fc14.src.rpm
Comment 15 Andreas Loening 2010-11-23 01:26:31 EST
Hi Mario,

I'm no autotools guru myself, and luckily everything else I've ever packaged was already an autoconf/libtool build system. dcmtk doesn't use (gnu) libtool, and without libtool doing it's automagic I'm pretty useless.

Is having sonames a strict requirement for package inclusion?
Comment 16 Mario Ceresa 2010-12-20 12:19:44 EST
Hello Andreas!
at last we discovered a nice github code with a lot of interesting fixes (https://github.com/commontk/DCMTK). One of them was the use of Cmake! Now I finally got proper soname libs so we should be able to finish it soon :)

The new code is in:
https://github.com/mrceresa/DCMTK

Mario
Comment 17 Per Inge Mathisen 2010-12-20 14:34:55 EST
The people behind DCMTK are currently in the process of releasing the next version (3.6.0 -- see http://support.dcmtk.org/wiki/dcmtk/notes/releaseplan360). I believe a snapshot of that is what you are seeing at commontk. At this point (since this has taken so long already), it might be just as well to wait for that release.
Comment 18 Andreas Loening 2010-12-22 01:08:13 EST
Wouldn't be a bad idea to wait a little more for the 3.6.0 release... These releases only occur every couple years.
Comment 19 Per Inge Mathisen 2011-01-07 03:48:53 EST
Version 3.6.0 is now released: http://dcmtk.org/dcmtk.php.en
Comment 20 Andreas Loening 2011-01-18 23:05:30 EST
I've gone ahead and updated the SPEC file for version 3.6.0, the relevant SPEC file and SRPM are at:

http://www.stanford.edu/~loening/fedora/

As with my prior rpm's, this builds shared libraries but does not include proper sonames.
Comment 21 Mario Ceresa 2011-02-03 13:16:48 EST
Hello all!
finally we got it. Packaged code is in:

https://github.com/mrceresa/dcmtk-offis

which follows the official dcmtk git up to 3.6.1 and adds:
 - proper shared lib soname generation.
 - reorganize files to conform with LFS

I still have to remove charls from the bundled libs as we did for gdcm. There should be no more but I'd rather check with care.

SPEC and SRPMS are as follows:

http://mrceresa.fedorapeople.org/dcmtk.spec
http://mrceresa.fedorapeople.org/dcmtk-3.6.1-1.20110203git.fc14.src.rpm

Best,
Mario
Comment 22 Mario Ceresa 2011-03-20 11:07:09 EDT
Hello again,
this time I rebased against official git repo, tag PUBLIC_360.

Also I removed charls and fixed (almost) all relevant errors. However there still is an error in how other libs links to dcmdata. This seems not be related to charls removal as happens also when all the relevant patches are disabled.

If you want to test it SPEC and SRPMS are as follows:

http://mrceresa.fedorapeople.org/dcmtk.spec
http://mrceresa.fedorapeople.org/dcmtk-3.6.0-1.fc14.src.rpm

Once we solve this I only have to bundle an ldconfig file to properly detect the newly installed libs.


Mario
Comment 23 Peter Lemenkov 2011-03-20 11:27:20 EDT
Hello!(In reply to comment #22)
> Hello again,

> ...However there
> still is an error in how other libs links to dcmdata. This seems not be related

[sorry, skipped]
 
> Once we solve this I only have to bundle an ldconfig file to properly detect
> the newly installed libs.

Do you mean that there is an issue with CMake detecting DCMTK libs or just with linking against them later? In the latter case - yes, you should consider providing your own ldconfig file. Just install a file, containing the following:

%{_libdir}/%{name}

into /etc/ld.so.conf.d and that's it. Take a look on how Qt resolves this issue. Otherwise your package looks good. Btw do you plan to update to 3.6.1?
Comment 24 Mario Ceresa 2011-03-20 14:37:04 EDT
Hey Peter! thanks for the hint on the ldconfig file, I'll try it out as soon as I'm able to fix this last linking error.

As far as I know ver 3.6.1 is the current development branch (master) I was tempted to rebase on it, but I thought that it was wiser to stick on a stable release, at least for now. What to do you think?
Comment 25 Mario Ceresa 2011-03-21 13:48:13 EDT
Done:

http://mrceresa.fedorapeople.org/dcmtk-3.6.0-2.fc14.src.rpm
http://mrceresa.fedorapeople.org/dcmtk.spec

I'll give myself a pat on the shoulder now :)
Comment 26 Per Inge Mathisen 2011-03-21 14:51:50 EDT
It is great to see activity on this again! I tried building the src rpm on Fedora 13, and that worked, but on install I got this:

bash-4.1# rpm -Uvh rpmbuild/RPMS/x86_64/dcmtk-3.6.0-2.fc13.x86_64.rpm 
error: Failed dependencies:
	libdcmdsig.so()(64bit) is needed by dcmtk-3.6.0-2.fc13.x86_64
	libijg12.so()(64bit) is needed by dcmtk-3.6.0-2.fc13.x86_64
	libijg16.so()(64bit) is needed by dcmtk-3.6.0-2.fc13.x86_64
	libijg8.so()(64bit) is needed by dcmtk-3.6.0-2.fc13.x86_64
	liblibi2d.so()(64bit) is needed by dcmtk-3.6.0-2.fc13.x86_64

Not sure why.
Comment 27 Peter Lemenkov 2011-03-22 08:59:34 EDT
(In reply to comment #26)
> It is great to see activity on this again! I tried building the src rpm on
> Fedora 13, and that worked, but on install I got this:
> 
> bash-4.1# rpm -Uvh rpmbuild/RPMS/x86_64/dcmtk-3.6.0-2.fc13.x86_64.rpm 
> error: Failed dependencies:
>  libdcmdsig.so()(64bit) is needed by dcmtk-3.6.0-2.fc13.x86_64
>  libijg12.so()(64bit) is needed by dcmtk-3.6.0-2.fc13.x86_64
>  libijg16.so()(64bit) is needed by dcmtk-3.6.0-2.fc13.x86_64
>  libijg8.so()(64bit) is needed by dcmtk-3.6.0-2.fc13.x86_64
>  liblibi2d.so()(64bit) is needed by dcmtk-3.6.0-2.fc13.x86_64
> 
> Not sure why.

They were moved by mistake to -devel subpackage because they don't have a versioned suffix (as other libraries). This is an issue and must be fixed.

Mario, you forgot to add cmake to the buildrequires and I commented out man-pages from %files in order to build it. See koji build-log:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2931897
Comment 28 Mario Ceresa 2011-03-22 13:47:09 EDT
Ok let's try again:

http://mrceresa.fedorapeople.org/dcmtk-3.6.0-3.fc14.src.rpm
http://mrceresa.fedorapeople.org/dcmtk.spec

Added cmake br. I don't understand why it doesn't find the man pages:
http://koji.fedoraproject.org/koji/getfile?taskID=2933305&name=build.log

In my workstation compiles and installs just fine... *puzzled*

Best

Mario
Comment 29 Per Inge Mathisen 2011-03-22 14:33:34 EDT
Now it works fine here, as well. Great work.
Comment 30 Mario Ceresa 2011-04-20 10:14:01 EDT
Peter: this solves the koji build error. man pages were missing because doxygen was not listed in the BRs.

http://mrceresa.fedorapeople.org/dcmtk-3.6.0-4.fc14.src.rpm
http://mrceresa.fedorapeople.org/dcmtk.spec

Now it builds correctly:

http://koji.fedoraproject.org/koji/taskinfo?taskID=3013850
Comment 31 Peter Lemenkov 2011-04-20 10:43:28 EDT
Ok, good.

REVIEW:

Legend: + = PASSED, - = FAILED, 0 = Not Applicable

+ rpmlint is not silent however all its messages can be safely omitted:


work ~: rpmlint ~/Desktop/dcmtk-*
dcmtk.src: W: spelling-error Summary(en_US) Offis -> Offs, Offish, Off is
dcmtk.src: W: spelling-error %description -l en_US worklist -> work list, work-list, workstation

^^^ false positive 

dcmtk.src:92: W: macro-in-comment %{name}
dcmtk.src:93: W: macro-in-comment %{name}
dcmtk.src:94: W: macro-in-comment %{_lib}
dcmtk.src:94: W: macro-in-comment %{name}
dcmtk.src:112: W: macro-in-comment %{buildroot}
dcmtk.src:112: W: macro-in-comment %{_lib}
dcmtk.src:112: W: macro-in-comment %{name}
dcmtk.src:113: W: macro-in-comment %{buildroot}
dcmtk.src:113: W: macro-in-comment %{_lib}
dcmtk.src:113: W: macro-in-comment %{buildroot}
dcmtk.src:113: W: macro-in-comment %{_lib}
dcmtk.src:113: W: macro-in-comment %{name}
dcmtk.src:135: W: macro-in-comment %{_sysconfdir}
dcmtk.src:135: W: macro-in-comment %{name}

^^^ that's ok - just a commented out strings. You should just remove them later 

dcmtk.src:69: W: mixed-use-of-spaces-and-tabs (spaces: line 68, tab: line 69)

^^ cosmetic.

dcmtk.x86_64: W: spelling-error Summary(en_US) Offis -> Offs, Offish, Off is
dcmtk.x86_64: W: spelling-error %description -l en_US worklist -> work list, work-list, workstation

^^^ false positives

dcmtk.x86_64: W: conffile-without-noreplace-flag /etc/ld.so.conf.d/dcmtk.conf

^^^ That's by design. This file isn't designed to be replaced by user.

dcmtk.x86_64: W: no-manual-page-for-binary dcmsign-3.6.0

^^^ that's ok.

dcmtk-devel.x86_64: W: only-non-binary-in-usr-lib

^^^ false positive.

dcmtk-devel.x86_64: W: no-documentation

^^^ by design - we just don't provide any docs with devel sub-package.

4 packages and 0 specfiles checked; 0 errors, 23 warnings.
work ~: 

+ The package is named according to the  Package Naming Guidelines.
+ The spec file name matches the base package %{name}, in the format %{name}.spec.
+ The package meets the Packaging Guidelines.
+ The package is licensed with a Fedora approved license and meets the Licensing Guidelines.
+ The License field in the package spec file matches the actual license.
+ The file, containing the text of the license(s) for the package, is included in %doc.
+ The spec file is written in American English.
+ The spec file for the package is legible.
+ The sources used to build the package, match the upstream source, as provided in the spec URL.

sulaco ~/rpmbuild/SOURCES: sha256sum dcmtk-3.6.0.tar.gz*
cfc509701122adfa359f1ee160e943c1548c7696b607dbb646c5a06f015ed33a  dcmtk-3.6.0.tar.gz
cfc509701122adfa359f1ee160e943c1548c7696b607dbb646c5a06f015ed33a  dcmtk-3.6.0.tar.gz.1
sulaco ~/rpmbuild/SOURCES:

+ The package successfully compiles and builds into binary rpms on at least one primary architecture. See koji link above.
+ All build dependencies are listed in BuildRequires.
0 No need to handle locales.
+ The package stores shared library files in some of the dynamic linker's default paths, and it calls ldconfig in %post and %postun.
+ The package does NOT bundle copies of system libraries.
0 The package is not designed to be relocatable.

- The package MUST  own all directories that it creates. The following directories are left unowned:

/etc/dcmtk
/usr/lib64/dcmtk
/usr/share/dcmtk
/usr/share/doc/dcmtk-3.6.0


+ The package does not list a file more than once in the spec file's %files listings.
+ Permissions on files are set properly.
+ The package has a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
+ The package consistently uses macros.
+ The package contains code, or permissible content.
0 No extremely large documentation files.
+ Anything, the package includes as %doc, does not affect the runtime of the application.
+ Header files are stored in a -devel package.
0 No static libraries.
0 No pkgconfig(.pc) files.
+ The library file(s) that end in .so (without suffix) is(are) stored in a -devel package.
+ The -devel package requires the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}
+ The package does NOT contain any .la libtool archives.
0 Not a GUI application.
+ The package does not own files or directories already owned by other packages.
+ At the beginning of %install, the package runs rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
+ All filenames in rpm packages are valid UTF-8.

Ok, please claim ownership on the directories mentioned above, and I'll continue.
Comment 33 Mario Ceresa 2011-04-20 11:12:42 EDT
The link to the srpms is:
http://mrceresa.fedorapeople.org/dcmtk-3.6.0-5.fc14.src.rpm
Comment 34 Peter Lemenkov 2011-04-20 11:32:25 EDT
Ok, good. This package is

APPROVED.
Comment 35 Mario Ceresa 2011-04-20 12:01:03 EDT
New Package SCM Request
=======================
Package Name: dcmtk
Short Description: Offis DICOM Toolkit
Owners: mrceresa
Branches: f14 f15 el6
InitialCC: peter
Comment 36 Jason Tibbitts 2011-04-20 23:33:01 EDT
Git done (by process-git-requests).
Comment 37 Fedora Update System 2011-04-21 06:22:26 EDT
dcmtk-3.6.0-5.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/dcmtk-3.6.0-5.fc14
Comment 38 Fedora Update System 2011-04-21 06:36:36 EDT
dcmtk-3.6.0-5.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/dcmtk-3.6.0-5.fc15
Comment 39 Fedora Update System 2011-04-21 18:24:05 EDT
dcmtk-3.6.0-5.fc14 has been pushed to the Fedora 14 testing repository.
Comment 40 Fedora Update System 2011-04-26 12:26:27 EDT
dcmtk-3.6.0-5.fc15 has been pushed to the Fedora 15 stable repository.
Comment 41 Fedora Update System 2011-04-29 18:20:08 EDT
dcmtk-3.6.0-5.fc14 has been pushed to the Fedora 14 stable repository.

Note You need to log in before you can comment on or make changes to this bug.