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.
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
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
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).
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
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?
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.
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
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?
(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
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 :)
I'll review it. Andreas, are you still interested in packaging this or will you hand over it to Mario?
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?
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
The most updated srpms is here: http://mrceresa.fedorapeople.org/dcmtk-3.5.4-4.fc14.src.rpm
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?
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
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.
Wouldn't be a bad idea to wait a little more for the 3.6.0 release... These releases only occur every couple years.
Version 3.6.0 is now released: http://dcmtk.org/dcmtk.php.en
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.
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
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
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?
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?
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 :)
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.
(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
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
Now it works fine here, as well. Great work.
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
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.
done! sorry for that... http://mrceresa.fedorapeople.org/dcmtk.spec http://mrceresa.fedorapeople.org/dcmtk-3.6.0-5.fc14.x86_64.rpm
The link to the srpms is: http://mrceresa.fedorapeople.org/dcmtk-3.6.0-5.fc14.src.rpm
Ok, good. This package is APPROVED.
New Package SCM Request ======================= Package Name: dcmtk Short Description: Offis DICOM Toolkit Owners: mrceresa Branches: f14 f15 el6 InitialCC: peter
Git done (by process-git-requests).
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
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
dcmtk-3.6.0-5.fc14 has been pushed to the Fedora 14 testing repository.
dcmtk-3.6.0-5.fc15 has been pushed to the Fedora 15 stable repository.
dcmtk-3.6.0-5.fc14 has been pushed to the Fedora 14 stable repository.