Package Details: dcmtk 3.6.8-1

Git Clone URL: https://aur.archlinux.org/dcmtk.git (read-only, click to copy)
Package Base: dcmtk
Description: A collection of libraries and applications implementing large parts the DICOM standard
Upstream URL: http://dicom.offis.de/dcmtk
Licenses: Other
Submitter: Skatox
Maintainer: Skatox
Last Packager: Skatox
Votes: 54
Popularity: 0.000002
First Submitted: 2008-11-07 13:14 (UTC)
Last Updated: 2024-02-25 14:45 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 Next › Last »

Skatox commented on 2018-03-13 12:47 (UTC)

@haawda thanks for the report, updated.

haawda commented on 2018-03-13 07:40 (UTC)

Installs libs to /usr/lib64 for me. Adding

-DCMAKE_INSTALL_LIBDIR:PATH=lib \

-DCMAKE_INSTALL_LIBEXECDIR:PATH=lib

to the cmake command prevents this.

farbeiza commented on 2018-03-12 22:55 (UTC) (edited on 2018-03-12 22:58 (UTC) by farbeiza)

When installing the package, I am getting this error:

error: failed to commit transaction (conflicting files)
dcmtk: /usr/lib64 exists in filesystem
Errors occurred, no packages were upgraded.

I am finding some old posts about a similar problem, but I do not think it is the same problem now.

Is anyone getting something like this?

Skatox commented on 2018-03-12 03:25 (UTC)

Updated to 3.6.3 now it uses included Charls code. No fedora patches.

jas commented on 2018-02-08 21:04 (UTC) (edited on 2018-02-08 21:05 (UTC) by jas)

"The upstream developers should be contacted."

I'm listening ;-) Making our included (and often also modified) versions of the third party libraries interchangable by the ones provided by the OS is something we certainly want to do, but don't quite find the time for. If you were to propose a patch I could at least add it to our issue tracker and maybe someone will find the time to review and finally commit it.

Regarding CharLS we already have this as a feature request:

http://support.dcmtk.org/redmine/issues/344

And we also have:

http://support.dcmtk.org/redmine/issues/403

amos commented on 2018-01-16 14:31 (UTC)

I tried to get it working with charls 2.0, but they changed too much to maintain in downstream patches (names, enums -> enum classes, etc.). The upstream developers should be contacted. In the meantime, I guess the reasonable option is to drop both the patches and the removal of the CharLS they ship. Or depend strictly on CharLS<2.0, but that's probably inconvenient.

Skatox commented on 2018-01-15 16:50 (UTC)

You're right. I have charls1 installed. Should I keep fedora patches or leave it without them?

amos commented on 2018-01-15 16:29 (UTC) (edited on 2018-01-15 16:30 (UTC) by amos) 

In file included from /var/cache/pacman/pkg/dcmtk31739/dcmtk/src/dcmtk-3.6.2/dcmjpls/libsrc/djcodecd.cc:37:0:
/var/cache/pacman/pkg/dcmtk31739/dcmtk/src/dcmtk-3.6.2/dcmjpls/libsrc/djerror.h:27:10: fatal error: CharLS/interface.h: No such file or directory
 #include "CharLS/interface.h" /* CharLS include */

The fedora patches are for CharLS 1.0, but probably not for CharLS 2.0.

Skatox commented on 2018-01-15 04:57 (UTC)

Updated to include Fedora's patches.

Skatox commented on 2017-07-29 22:33 (UTC)

Updated to stable 3.6.2 version, currently uses bundled charls library. I will wait for Fedora's patches to release a version with Arch's charls.

« First ‹ Previous 1 2 3 4 5 6 7 8 9 Next › Last »