Bug#1010210: ITP: orthanc-neuro -- Neuroimaging plugin for Orthanc
Package: wnpp Severity: wishlist Owner: Sebastien Jodogne X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: orthanc-neuro Version : 1.0 Upstream Author : Sebastien Jodogne * URL : https://book.orthanc-server.com/plugins/neuro.html * License : GPL Programming Lang: C++ Description : Neuroimaging plugin for Orthanc This package adds support for neuroimaging in Orthanc, notably to easily convert from DICOM to NIfTI.
Bug#989613: unblock: orthanc-dicomweb/1.5+dfsg-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package orthanc-dicomweb
[ Reason ]
This version fixes issue #989128 (package statically links without using a
Built-Using attribute), that has the "serious" severity.
[ Impact ]
None, as no other package depends on this package.
[ Tests ]
I have run the upstream unit tests, as well as the upstream integration tests.
[ Risks ]
As can be seen in the debdiff, the only modification wrt. the version currently
in testing (orthanc-dicomweb/1.5+dfsg-2) is the addition of the "Built-Using"
attribute on the binary package. So, I see no potential risk.
Many thanks in advance,
Sébastien-
unblock orthanc-dicomweb/1.5+dfsg-3
diff -Nru orthanc-dicomweb-1.5+dfsg/debian/changelog
orthanc-dicomweb-1.5+dfsg/debian/changelog
--- orthanc-dicomweb-1.5+dfsg/debian/changelog 2021-02-26 15:25:00.0
+0100
+++ orthanc-dicomweb-1.5+dfsg/debian/changelog 2021-06-07 11:17:44.0
+0200
@@ -1,3 +1,10 @@
+orthanc-dicomweb (1.5+dfsg-3) unstable; urgency=medium
+
+ * Added missing "Built-Using" attribute (backport from experimental).
+Closes: #989128
+
+ -- Sebastien Jodogne Mon, 07 Jun 2021 11:17:44 +0200
+
orthanc-dicomweb (1.5+dfsg-2) unstable; urgency=medium
* Statically link against the Orthanc framework
diff -Nru orthanc-dicomweb-1.5+dfsg/debian/control
orthanc-dicomweb-1.5+dfsg/debian/control
--- orthanc-dicomweb-1.5+dfsg/debian/control2021-02-26 15:25:00.0
+0100
+++ orthanc-dicomweb-1.5+dfsg/debian/control2021-06-07 11:17:44.0
+0200
@@ -26,6 +26,7 @@
Depends: ${misc:Depends},
${shlibs:Depends},
orthanc (>= 1.7.0)
+Built-Using: ${orthancframework:Built-Using}
Description: Plugin to extend Orthanc with support of WADO and DICOMweb
Orthanc DICOMweb is a plugin to Orthanc, the lightweight, RESTful Vendor
Neutral Archive for medical imaging. It extends the Orthanc core with
diff -Nru orthanc-dicomweb-1.5+dfsg/debian/rules
orthanc-dicomweb-1.5+dfsg/debian/rules
--- orthanc-dicomweb-1.5+dfsg/debian/rules 2021-02-26 15:25:00.0
+0100
+++ orthanc-dicomweb-1.5+dfsg/debian/rules 2021-06-07 11:17:44.0
+0200
@@ -24,6 +24,13 @@
"-DORTHANC_FRAMEWORK_ADDITIONAL_LIBRARIES=boost_filesystem
boost_iostreams boost_locale boost_regex boost_thread jsoncpp pugixml uuid
sqlite3 dcmdata dcmjpeg dcmjpls ofstd dcmimage" \
-DCMAKE_BUILD_TYPE=None # The build type must be set to None, see
#711515
+# Automated generation of the "Built-Using" attribute in "d/control"
+# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989128
+# Adapted from:
+# https://wiki.debian.org/SIMDEverywhere#Approach (Point 6)
+override_dh_gencontrol:
+ dh_gencontrol -- -Vorthancframework:Built-Using="$(shell dpkg-query -f
'$${source:Package} (= $${source:Version}), ' -W liborthancframework-dev)"
+
override_dh_auto_configure:
# Place back the jquery library from Debian
cp /usr/share/javascript/jquery/jquery.min.js
Resources/Samples/JavaScript/jquery.min.js
Bug#989611: unblock: orthanc-wsi/1.0-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package orthanc-wsi
[ Reason ]
This version fixes issue #989126 (package statically links without using a
Built-Using attribute), that has the "serious" severity.
[ Impact ]
None, as no other package depends on this package.
[ Tests ]
I have run the upstream unit tests, as well as the upstream integration tests.
[ Risks ]
As can be seen in the debdiff, the only modification wrt. the version currently
in testing (orthanc-wsi/1.0-2) is the addition of the "Built-Using" attribute
on the binary package. So, I see no potential risk.
Many thanks in advance,
Sébastien-
unblock orthanc-wsi/1.0-3
diff -Nru orthanc-wsi-1.0/debian/changelog orthanc-wsi-1.0/debian/changelog
--- orthanc-wsi-1.0/debian/changelog2021-02-26 16:01:23.0 +0100
+++ orthanc-wsi-1.0/debian/changelog2021-06-07 14:34:06.0 +0200
@@ -1,3 +1,9 @@
+orthanc-wsi (1.0-3) unstable; urgency=medium
+
+ * Added missing "Built-Using" attribute. Closes: #989126
+
+ -- Sebastien Jodogne Mon, 07 Jun 2021 14:34:06 +0200
+
orthanc-wsi (1.0-2) unstable; urgency=medium
* Statically link against the Orthanc framework
diff -Nru orthanc-wsi-1.0/debian/control orthanc-wsi-1.0/debian/control
--- orthanc-wsi-1.0/debian/control 2021-02-26 16:01:23.0 +0100
+++ orthanc-wsi-1.0/debian/control 2021-06-07 14:34:06.0 +0200
@@ -24,6 +24,7 @@
Architecture: any
Depends: ${misc:Depends},
${shlibs:Depends}
+Built-Using: ${orthancframework:Built-Using}
Recommends: orthanc (>= 1.1.0),
libopenslide0
Description: Whole-slide imaging support for Orthanc (digital pathology)
diff -Nru orthanc-wsi-1.0/debian/rules orthanc-wsi-1.0/debian/rules
--- orthanc-wsi-1.0/debian/rules2021-02-26 16:01:23.0 +0100
+++ orthanc-wsi-1.0/debian/rules2021-06-07 14:34:06.0 +0200
@@ -33,6 +33,13 @@
-DOPENLAYERS_JS=$(CURDIR)/BuildViewer/ol.min.js \
-DCMAKE_BUILD_TYPE=None # The build type must be set to None, see
#711515
+# Automated generation of the "Built-Using" attribute in "d/control"
+# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989126
+# Adapted from:
+# https://wiki.debian.org/SIMDEverywhere#Approach (Point 6)
+override_dh_gencontrol:
+ dh_gencontrol -- -Vorthancframework:Built-Using="$(shell dpkg-query -f
'$${source:Package} (= $${source:Version}), ' -W liborthancframework-dev)"
+
override_dh_auto_configure:
# Configure the command-line tools
mkdir BuildApplications
Bug#989610: unblock: orthanc-webviewer/2.7-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package orthanc-webviewer
[ Reason ]
This version fixes issue #989127 (package statically links without using a
Built-Using attribute), that has the "serious" severity.
[ Impact ]
None, as no other package depends on this package.
[ Tests ]
I have run the upstream unit tests, as well as the upstream integration tests.
[ Risks ]
As can be seen in the debdiff, the only modification wrt. the version currently
in testing (orthanc-webviewer/2.7-3) is the addition of the "Built-Using"
attribute on the binary package. So, I see no potential risk.
Many thanks in advance,
Sébastien-
unblock orthanc-webviewer/2.7-4
diff -Nru orthanc-webviewer-2.7/debian/changelog
orthanc-webviewer-2.7/debian/changelog
--- orthanc-webviewer-2.7/debian/changelog 2021-02-26 14:41:24.0
+0100
+++ orthanc-webviewer-2.7/debian/changelog 2021-06-07 14:21:25.0
+0200
@@ -1,3 +1,9 @@
+orthanc-webviewer (2.7-4) unstable; urgency=medium
+
+ * Added missing "Built-Using" attribute. Closes: #989127
+
+ -- Sebastien Jodogne Mon, 07 Jun 2021 14:21:25 +0200
+
orthanc-webviewer (2.7-3) unstable; urgency=medium
* Statically link against the Orthanc framework
diff -Nru orthanc-webviewer-2.7/debian/control
orthanc-webviewer-2.7/debian/control
--- orthanc-webviewer-2.7/debian/control2021-02-26 14:38:57.0
+0100
+++ orthanc-webviewer-2.7/debian/control2021-06-07 14:21:25.0
+0200
@@ -29,6 +29,7 @@
Depends: ${misc:Depends},
${shlibs:Depends},
orthanc (>= 1.7.1)
+Built-Using: ${orthancframework:Built-Using}
Description: Web viewer of medical images for Orthanc
Orthanc Web Viewer is a plugin to Orthanc, a lightweight, RESTful Vendor
Neutral Archive for medical imaging. It extends Orthanc with an integrated
diff -Nru orthanc-webviewer-2.7/debian/rules orthanc-webviewer-2.7/debian/rules
--- orthanc-webviewer-2.7/debian/rules 2021-02-26 14:41:24.0 +0100
+++ orthanc-webviewer-2.7/debian/rules 2021-06-07 14:21:25.0 +0200
@@ -26,6 +26,13 @@
"-DORTHANC_FRAMEWORK_ADDITIONAL_LIBRARIES=boost_filesystem
boost_iostreams boost_locale boost_regex boost_thread jsoncpp pugixml uuid
sqlite3" \
-DCMAKE_BUILD_TYPE=None # The build type must be set to None, see
#711515
+# Automated generation of the "Built-Using" attribute in "d/control"
+# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989127
+# Adapted from:
+# https://wiki.debian.org/SIMDEverywhere#Approach (Point 6)
+override_dh_gencontrol:
+ dh_gencontrol -- -Vorthancframework:Built-Using="$(shell dpkg-query -f
'$${source:Package} (= $${source:Version}), ' -W liborthancframework-dev)"
+
override_dh_auto_configure:
# Place the third-party JavaScript libraries at the location
# expected by CMake
Bug#975069: emscripten: Incompatibilities with LLVM 11
Package: emscripten Version: 2.0.8~dfsg1-9 Severity: important Dear Maintainer, When building a large C++ project using the current package, the WebAssembly linking might fail with error "emscripten:ERROR: emscript: failure to parse metadata output from wasm-emscripten-finalize". It turns out that such error is a consequence of the fact that Emscripten 2.0.x is expected to be run with LLVM 12. But, the patch "d/patches/2005_older_llvm.patch" allows to run Emscripten with LLVM 11, which might result in incompatibilities. More context is available in the following issue of the upstream project: https://github.com/emscripten-core/emscripten/issues/11895 This issue can be closed once LLVM 12 will land in Debian Sid, once "d/control" is adapted to use version 12 on all LLVM-related packages, and once the "d/patches/2005_older_llvm.patch" is removed. Best Regards, Sébastien- -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages emscripten depends on: ii binaryen 98-1 ii clang-11 1:11.0.0-5 ii lld-11 1:11.0.0-5 ii llvm-111:11.0.0-5 ii node-debbundle-acorn [node-acorn] 8.0.4+ds+~cs19.19.27-1 ii nodejs 12.19.0~dfsg-1 ii python33.8.6-1 Versions of packages emscripten recommends: ii libjs-d3 3.5.17-2 ii python3-numpy 1:1.19.4-1 Versions of packages emscripten suggests: pn adb ii automake 1:1.16.2-4 pn closure-compiler ii cmake 3.18.4-1 ii make 4.3-4 ii python3-ply 3.11-4 ii scons 4.0.1+dfsg-2 ii wabt 1.0.20-1 -- no debconf information -- debsums errors found: debsums: changed file /usr/share/emscripten/emscripten.py (from emscripten package)
Bug#961716: ITP: orthanc-gdcm -- Transcoder/decoder of DICOM images for Orthanc using GDCM
Package: wnpp Severity: wishlist Owner: Sebastien Jodogne * Package name: orthanc-gdcm Version : 1.0 Upstream Author : Sebastien Jodogne * URL : https://www.orthanc-server.com/ * License : GPL Programming Lang: C++ Description : Transcoder/decoder of DICOM images for Orthanc using GDCM This package installs a plugin for Orthanc (lightweight, RESTful Vendor Neutral Archive for medical imaging). The plugin extends Orthanc with a transcoder/decoder of DICOM images that is built on the GDCM library, whereas the built-in transcoder/decoder of Orthanc uses DCMTK.
Bug#955495: ITP: orthanc-python -- Develop plugins for Orthanc using the Python programming language
Package: wnpp Severity: wishlist Owner: Sebastien Jodogne * Package name: orthanc-python Version : 1.0 Upstream Author : Sebastien Jodogne * URL : https://www.orthanc-server.com/ * License : AGPL Programming Lang: C++, Python Description : Develop plugins for Orthanc using the Python programming language This plugin can be used to write Orthanc plugins using the Python programming language instead of the more complex C/C++ programming languages. It can be used to gain access to Python modules directly in Orthanc. This plugin can be of great help to anyone wishing to automate her imaging workflow, to design/train new machine learning algorithms, or to deploy AI systems directly in clinical setups. Full documentation is available in the Orthanc Book: https://book.orthanc-server.com/plugins/python.html
Bug#944732: RM: orthanc-dicomweb [armel] -- ROM; node-axios is not available on armel
Package: ftp.debian.org Severity: normal The reason for this removal is discussed in bug Bug#944671: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944671 Note: this was a request for a partial removal from testing, converted in one for unstable
Bug#903973: ITP: orthanc-mysql -- Plugins to use MySQL or MariaDB as a database back-end to Orthanc
Package: wnpp Severity: wishlist Owner: Sebastien Jodogne * Package name: orthanc-mysql Version : 1.0 Upstream Author : Sebastien Jodogne * URL : https://www.orthanc-server.com/static.php?page=mysql * License : AGPL Programming Lang: C++ Description : Plugins to use MySQL or MariaDB as a database back-end to Orthanc Orthanc MySQL is a set of 2 plugins to Orthanc, a lightweight, RESTful Vendor Neutral Archive for medical imaging. These plugins override the default SQLite engine of Orthanc with a MySQL or MariaDB back-end. They bring scalability to Orthanc, making it enterprise-ready. This package should ideally be maintained by the Debian Med team, who already maintains Orthanc.
Bug#829380: Orthanc 1.2.0
Dear Karsten, Well, once Orthanc 1.2 shows up in my sources.lst I will test the suggested script and report back. Since I don't assume Orthanc 1.1 -> 1.2 to actually need a database upgrade (?) I expect the script to gracefully do nothing. Indeed, an upgrade of the Orthanc database is only necessary if the version of the DB changes. The internals are explained in the Orthanc Book: http://book.orthanc-server.com/developers/db-versioning.html The last modification of the DB schema was introduced in Orthanc 0.9.5 (released on December 2nd, 2015). This means that any post-0.9.5 release will transparently work without having to upgrade the database. Since that release, the database schema is now considered as stable, and no upgrade should be necessary. Furthermore, I personally feel that the upgrade process should imply a manual operation from the user. The official documentation of Orthanc clearly explains what should be done in such a case: http://book.orthanc-server.com/users/replication.html#upgrade-the-database-schema As a consequence, I am not convinced that providing an automated script is necessary. Maybe it would be sufficient to simply point to the section of the Orthanc Book above in the "README.Debian". HTH, Sébastien-
Bug#842168: ITP: orthanc-wsi -- Whole-slide imaging support for Orthanc (digital pathology)
Package: wnpp Severity: wishlist Owner: Sebastien Jodogne * Package name: orthanc-wsi Upstream Author : Sebastien Jodogne * URL : http://www.orthanc-server.com/static.php?page=wsi * License : AGPL Programming Lang: C++ Description : Whole-slide imaging support for Orthanc (digital pathology) The Orthanc project is a lightweight, extensible Vendor Neutral Archive for medical imaging (i.e. a DICOM server). It now provides a reference implementation of DICOM for whole-slide imaging (digital pathology), following DICOM Supplement 145. This package should be maintained by the Debian Med team, as it already maintains all the Orthanc-related packages.
Bug#829608: [Debian-med-packaging] Bug#829608: orthanc: ftbfs with new dcmtk
FYI, I have modified your original patch so as to be more bullet-proof wrt. future evolutions of the dcmtk package: http://anonscm.debian.org/cgit/debian-med/orthanc.git/commit/?id=8d9cbc2f8b4c8d6395ad59cee45ba92adf39b447 I dcutted the package from deferred, I'll be happy to sponsor an upload whenever you can (or ask your usual sponsor) Thanks! Andreas Tille is my usual sponsor, and it think he will take care of this upload: I have sent a ping on the Debian Med mailing list. I will get back in touch with you if this is not the case. Sébastien-
Bug#829608: [Debian-med-packaging] Bug#829608: orthanc: ftbfs with new dcmtk
Dear Gianfranco, Thanks for all the fix! FYI, I have modified your original patch so as to be more bullet-proof wrt. future evolutions of the dcmtk package: http://anonscm.debian.org/cgit/debian-med/orthanc.git/commit/?id=8d9cbc2f8b4c8d6395ad59cee45ba92adf39b447 This fix is also reintegrated in the upstream code of Orthanc: https://bitbucket.org/sjodogne/orthanc/commits/e92280e63d8dca20b2f2f1b1f525bd3c3f501513 Thanks again, Sébastien- On 07/04/2016 06:52 PM, Gianfranco Costamagna wrote: Source: orthanc Severity: serious Version: 1.1.0+dfsg-1 Tags: patch pending Hi, I'm uploading a fix in deferred/15, for this build failure. I'll attach the debdiff as soon as I have the bug report. Gianfranco
Bug#818757: Bug#818757: orthanc-postgresql: does not start
That's usually created automatically since a certain point of time if you build the package. I intended to verify this for orthanc-postgresql_2.0 but get a build error. :-( -- Could NOT find PostgreSQL (missing: PostgreSQL_TYPE_INCLUDE_DIR) (found version "9.5.3") There seems to be a similar bug reported in January: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811141 Karsten Indeed, this is the same issue! Just updated the changelog: https://anonscm.debian.org/viewvc/debian-med?view=revision&revision=22266 Thanks, Sébastien-
Bug#818757: Bug#818757: orthanc-postgresql: does not start
Hi Andreas, Oh... thanks for reporting this issue. It is now fixed: https://anonscm.debian.org/viewvc/debian-med?view=revision&revision=22265 Sébastien- > That's usually created automatically since a certain point of time if you build the package. I intended to verify this for orthanc-postgresql_2.0 but get a build error. :-( -- Could NOT find PostgreSQL (missing: PostgreSQL_TYPE_INCLUDE_DIR) (found version "9.5.3")
Bug#818757: [Debian-med-packaging] Bug#818757: orthanc-postgresql: does not start
>> After downloading the source code of each package, create a "Build" >> directory inside, and run: >> >> # cmake .. -DSTATIC_BUILD=ON -DCMAKE_BUILD_TYPE=Debug >> # make > > Attached a full backtrace of a stock Debian Orthanc 1.1.0 > with o-pg 2.0 (it is lacking symbols so might be of limited > use). Thanks, but unfortunately, this log does not show anything useful for debugging because of the lack of symbols. Couldn't you try and statically link Orthanc and Orthanc-PG in debug mode following the commands written above? Or, at least, compile the Debian package from source and modify the "debian/rules" so as to add "-DCMAKE_BUILD_TYPE=Debug"? Also, do you remember which versions of Orthanc and Orthanc-PG generated the database you try and upgrade? > Any chance a -dbgsyms package can be provided ? I have no idea of how this can be done in Debian together with CMake; I am unable to understand the wiki [1]. Furthermore, besides keeping the symbols, it would be really important to compile in Debug mode, otherwise the trace would be very hard to understand. Sébastien- [1] https://wiki.debian.org/DebugPackage
Bug#818757: [Debian-med-packaging] Bug#818757: orthanc-postgresql: does not start
In the former case, couldn't it be possible that the version of some shared library does not match its version of the headers, maybe because of an unstable Debian? That is surely possible. That is why I offered to provide more information if told how to do so. Yes, sorry about that: As mentioned earlier, I had no time to dig this problem further in the past weeks. Orthanc is huge, and I'm alone to work on its code. What I would need would be a full backtrace of the C++ code. This requires a fresh build in debug mode, with static linking, of both Orthanc 1.1.0 and PostgreSQL plugin 2.0. Static linking allows to become independent of a potential instability of your Debian setup. After downloading the source code of each package, create a "Build" directory inside, and run: # cmake .. -DSTATIC_BUILD=ON -DCMAKE_BUILD_TYPE=Debug # make Obviously, make sure that your Orthanc configuration points to the newly built PostgreSQL plugin. Then, please post the full gdb backtrace (command "bt") of the crash when you try and run "--upgrade". Sorry again and thanks for your collaboration, Sébastien-
Bug#821135: Bug#821135: imagej: Crash running imagej
Thanks for this additional information. Could you possibly verify this by starting some other openjdk based application? Thanks for confirming the reproducibility of this issue with imagej. Fortunately, this crash does not seem to occur when launching LibreOffice (that also depends on openjdk-8-jre). However, I was able to reproduce it with freecol (a free clone of the Colonization game available in Debian): > jodogne@unstable:~$ sudo apt-get install freecol jodogne@unstable:~$ freecol Disabling IPV6 network stack to work around bug #560056 on openjdk If you experience problems with connecting to remote servers, you can put it back by running Freecol this way: freecol --enable-ipv6 OpenJDK 64-Bit Server VM warning: Using incremental CMS is deprecated and will likely be removed in a future release # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x7f29bd127a8a, pid=6559, tid=139818483369728 # # JRE version: OpenJDK Runtime Environment (8.0_77-b01) (build 1.8.0_77-Debian-8u77-b03-3+b1-b1) # Java VM: OpenJDK 64-Bit Server VM (25.77-b1 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libatk-bridge-2.0.so.0+0x10a8a] # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/jodogne/hs_err_pid6559.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Aborted < FreeCol also crashes if invoked from ssh, but runs fine within a window manager. As a conclusion, we have at least two totally unrelated packages (imagej and freecol) that both crash if invoked from ssh. This most probably indicates that this issue should rather be filed against the "openjdk-8-jre" package. HTH, Sébastien-
Bug#821135: [Debian-med-packaging] Bug#821135: imagej: Crash running imagej
Hello, After further investigation, this crash only occurs when I invoke imagej through ssh (with the "-Y" flag). If I run imagej within some window manager (e.g. XFCE), everything goes fine. As a consequence, this looks more like a problem within openjdk. Sébastien- On 04/16/2016 09:55 AM, Sébastien Jodogne wrote: As a complement, you will find the full log attached to this post. HTH, Sébastien- On Fri, Apr 15, 2016 at 10:27 PM, Sebastien Jodogne mailto:s.jodo...@gmail.com>> wrote: Package: imagej Version: 1.50i+dfsg-1 Severity: important Dear Maintainer, When I try and run the ImageJ package from Debian Sid, I currently get the following crash: >>>>> jodogne@unstable:~$ rm -rf .imagej jodogne@unstable:~$ imagej Open other images in this ImageJ panel as follows: imagej -p 1 [ ... ] # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x7fe91d03ba8a, pid=1262, tid=140639753193216 # # JRE version: OpenJDK Runtime Environment (8.0_77-b01) (build 1.8.0_77-Debian-8u77-b03-3+b1-b1) # Java VM: OpenJDK 64-Bit Server VM (25.77-b1 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libatk-bridge-2.0.so.0+0x10a8a] # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/jodogne/hs_err_pid1262.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # /usr/bin/imagej: line 427: 1262 Aborted /usr/lib/jvm/java-1.8.0-openjdk-amd64/bin/java -d64 -mx474m -cp /usr/share/java/ij.jar ij.ImageJ -ijpath /home/jodogne/.imagej -port1 <<<<< This crash makes the imagej package totally unusable to me. I have removed and purged all the JRE and JDK packages before making a fresh installation of imagej, but the crash is still there. I thank you in advance for taking this problem into consideration!
Bug#821135: imagej: Crash running imagej
Package: imagej
Version: 1.50i+dfsg-1
Severity: important
Dear Maintainer,
When I try and run the ImageJ package from Debian Sid, I currently get the
following crash:
>
jodogne@unstable:~$ rm -rf .imagej
jodogne@unstable:~$ imagej
Open other images in this ImageJ panel as follows:
imagej -p 1 [ ... ]
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x7fe91d03ba8a, pid=1262, tid=140639753193216
#
# JRE version: OpenJDK Runtime Environment (8.0_77-b01) (build
1.8.0_77-Debian-8u77-b03-3+b1-b1)
# Java VM: OpenJDK 64-Bit Server VM (25.77-b1 mixed mode linux-amd64
compressed oops)
# Problematic frame:
# C [libatk-bridge-2.0.so.0+0x10a8a]
#
# Failed to write core dump. Core dumps have been disabled. To enable
core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/jodogne/hs_err_pid1262.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
/usr/bin/imagej: line 427: 1262 Aborted
/usr/lib/jvm/java-1.8.0-openjdk-amd64/bin/java -d64 -mx474m -cp
/usr/share/java/ij.jar ij.ImageJ -ijpath /home/jodogne/.imagej -port1
<
This crash makes the imagej package totally unusable to me.
I have removed and purged all the JRE and JDK packages before making a fresh
installation of imagej, but the crash is still there.
I thank you in advance for taking this problem into consideration!
Regards,
Sebastien-
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set
LC_ALL to default locale: No such file or directory
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages imagej depends on:
ii default-jre 2:1.8-57
imagej recommends no packages.
imagej suggests no packages.
-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "fr_BE.UTF-8",
LC_MONETARY = "fr_BE.UTF-8",
LC_ADDRESS = "fr_BE.UTF-8",
LC_TELEPHONE = "fr_BE.UTF-8",
LC_NAME = "fr_BE.UTF-8",
LC_MEASUREMENT = "fr_BE.UTF-8",
LC_IDENTIFICATION = "fr_BE.UTF-8",
LC_NUMERIC = "fr_BE.UTF-8",
LC_PAPER = "fr_BE.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory
Bug#821011: orthanc: FTBFS on powerpc/ppc64el: error: #error Support your plateform here
Hello, tested on plummer.d.o and it compiles fine :) [...] uploaded :) Great, thanks for your help and for uploading the package! PS, Sebastien: your MUA doesn't wrap the lines at all, and that makes particularly painful to read your email. I was not aware of this issue, thanks for letting me know. The Web interface of the Zimbra server that is installed in my hospital seems not to properly handle line wrapping. I will use Thunderbird from now on when posting to this mailing list. Regards, Sébastien-
Bug#819971: libjsoncpp-dev: Warnings about JSONCPP_OVERRIDE
Package: libjsoncpp-dev Version: 1.7.2-1 Severity: minor Dear Maintainer, When compiling against libjsoncpp, I get a huge number of warnings such as the following: /usr/include/jsoncpp/json/value.h:56:22: warning: override controls (override/final) only available with -std=c++11 or -std=gnu++11 ~Exception() throw() JSONCPP_OVERRIDE; This results from the fact that my software is compiled with all warnings enabled and using the 1998 ISO C++ standard (not 2011 ISO C++). I would suggest patching the definition of the macro JSONCPP_OVERRIDE in the file "/usr/include/jsoncpp/json/config.h" as follows: #if defined(_MSC_VER) && _MSC_VER <= 1600 // MSVC <= 2010 # define JSONCPP_OVERRIDE #elif (__cplusplus < 201103L) // 1998 ISO C++ # define JSONCPP_OVERRIDE #else // 2011 ISO C++ or above # define JSONCPP_OVERRIDE override #endif HTH, Sebastien- -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libjsoncpp-dev depends on: ii libjsoncpp1 1.7.2-1 libjsoncpp-dev recommends no packages. libjsoncpp-dev suggests no packages. -- no debconf information
Bug#802756: Package name
Hi Yves, This is great news! Just a suggestion: Wouldn't it be interesting to use the name "orthanc-dwv" instead of "dwv-orthanc-plugin"? Indeed, all the plugin packages related to Orthanc share the "orthanc-" prefix in Debian. Thanks for your contributions, Sébastien-
Bug#794392: ITP: orthanc-dicomweb -- Plugin to extend Orthanc with support of WADO and DICOMweb
Package: wnpp Severity: wishlist Owner: Sebastien Jodogne * Package name: orthanc-dicomweb Version : 0.1 Upstream Author : Sebastien Jodogne * URL : http://www.orthanc-server.com/static.php?page=dicomweb * License : AGPL Programming Lang: C++ Description : Plugin to extend Orthanc with support of WADO and DICOMweb Orthanc Web Viewer is a plugin to Orthanc, the lightweight, RESTful Vendor Neutral Archive for medical imaging. It extends the Orthanc core with support of the WADO and DICOMweb (QIDO-RS, STOW-RS, WADO-RS) standards. This package should ideally be maintained by the Debian Med team, who already maintains Orthanc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#779327: ITP: orthanc-postgresql -- Plugins to use PostgreSQL as a database back-end to Orthanc
Package: wnpp Severity: wishlist Owner: Sebastien Jodogne * Package name: orthanc-postgresql Version : 1.0 Upstream Author : Sebastien Jodogne * URL : https://code.google.com/p/orthanc-postgresql/ * License : AGPL Programming Lang: C++ Description : Plugins to use PostgreSQL as a database back-end to Orthanc Orthanc PostgreSQL are a set of 2 plugins to Orthanc, a lightweight, RESTful Vendor Neutral Archive for medical imaging. These plugins override the default SQLite engine of Orthanc with a PostgreSQL back-end. They bring scalability to Orthanc, making it enterprise-ready. This package should ideally be maintained by the Debian Med team, who already maintains Orthanc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#779325: ITP: orthanc-webviewer -- Web viewer of medical images for Orthanc
Package: wnpp Severity: wishlist Owner: Sebastien Jodogne * Package name: orthanc-webviewer Version : 1.0 Upstream Author : Sebastien Jodogne * URL : https://code.google.com/p/orthanc-webviewer/ * License : AGPL Programming Lang: C++ Description : Web viewer of medical images for Orthanc Orthanc Web Viewer is a plugin to Orthanc, a lightweight, RESTful Vendor Neutral Archive for medical imaging. It extends Orthanc with an integrated Web viewer of DICOM images. This package should ideally be maintained by the Debian Med team, who already maintains Orthanc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772561: ITP: orthanc-imagej -- ImageJ plugin to import images from Orthanc
Package: wnpp Severity: wishlist Owner: Sebastien Jodogne * Package name: orthanc-imagej Version : 1.0.0 Upstream Author : Sebastien Jodogne * URL : https://code.google.com/p/orthanc-imagej/ * License : GPL Programming Lang: Java Description : ImageJ plugin to import images from Orthanc A plugin for ImageJ to browse the content of an Orthanc server, then import 2D/3D DICOM images from Orthanc into ImageJ. This plugin hopefully greatly simplifies the indexation of DICOM images when dealing with ImageJ (e.g. for quality control of DICOM modalities, or for pedagogical use). There is also no need to carry on any complex network configuration, since the plugin directly uses the REST API of Orthanc. This makes its installation and its use quite straightforward. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761640: orthanc: new upstream available
Dear Karsten, I am currently working on the update of the Debian package, but some Lintian issues are to be properly addressed [1]. It should be available soon. Cheers, Sébastien- [1] https://lists.debian.org/debian-med/2014/09/msg00064.html On 09/15/2014 12:13 PM, Karsten Hilbert wrote: Package: orthanc Version: 0.8.2+dfsg-1 Severity: wishlist Tags: upstream Hi, upstream has released a new version 0.8.3. This version introduces one feature (DICOMDIR creation) which is very useful for my patients (with that feature I can hand to them CD-ROMs of their medical images ready for use at another doctor's office). It would be really nice if that feature / version would make it into Jessie. Thanks, Karsten -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (10, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.16-trunk-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages orthanc depends on: ii adduser3.113+nmu3 ii dcmtk 3.6.1~20131114-4 ii libboost-filesystem1.55.0 1.55.0+dfsg-2 ii libboost-locale1.55.0 1.55.0+dfsg-2 ii libboost-regex1.55.0 1.55.0+dfsg-2 ii libboost-system1.55.0 1.55.0+dfsg-2 ii libboost-thread1.55.0 1.55.0+dfsg-2 ii libc6 2.19-10 ii libcurl3 7.37.1-1 ii libdcmtk2 3.6.0-15+b1 ii libgcc11:4.9.1-12 ii libgoogle-glog00.3.3-2 ii libjsoncpp00.6.0~rc2-3 ii liblua5.1-05.1.5-7 ii libpng12-0 1.2.50-2 ii libpugixml11.2-2 ii libsqlite3-0 3.8.6-1 ii libssl1.0.01.0.1i-2 ii libstdc++6 4.9.1-12 ii libuuid1 2.20.1-5.8 ii zlib1g 1:1.2.8.dfsg-1 orthanc recommends no packages. orthanc suggests no packages. -- Configuration Files: /etc/init.d/orthanc changed [not included] /etc/orthanc/orthanc.json changed [not included] -- no debconf information -- Sébastien Jodogne, PhD. Medical Imaging Engineer Department of Medical Physics C.H.U. - SART TILMAN - B35 BAT. T1-3 RADIOTHERAPIE 4000 Liège BELGIUM Tel 1: +32 4 3667518 Tel 2: +32 4 3667596 Mail: s.jodo...@chu.ulg.ac.be Web: http://www.montefiore.ulg.ac.be/~jodogne/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751695: Fix
Dear Michael, Thanks for reporting this issue! A fix has been submitted to the Debian Med repository [0]. It should be available soon as a Debian package. Regards, Sébastien- [0] http://anonscm.debian.org/viewvc/debian-med?view=revision&revision=17174 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737448: [src:orthanc ] Sourceless file (minified)
Hello Andreas, Am I allowed to create symbolic links in the "override_dh_auto_configure" sections? Sure: override_dh_auto_configure # either do symlink or use some compression of the source # files to the place you need here dh_auto_configure ... Thanks to your helpful explanations, I think I have solved this bug together with the packaging of the new upstream version 0.7.3 of Orthanc [1]. The proper "Files-Excluded" directive is included in the copyright file [2], so that there remains only non-minified JavaScript files from the source package. Minified JavaScript files are re-generated using yui-compressor [3]. However, I would need an independent review to be sure that I have properly fixed the package. In particular, I had to introduce the "+dfsg" suffix to the package version: I am unsure whether this is the proper way of doing things. Would you kindly have a look at my modifications, possibly uploading it if everything is OK? Regards, Sébastien- [1] http://anonscm.debian.org/viewvc/debian-med/trunk/packages/orthanc/trunk/debian/JS/ [2] http://anonscm.debian.org/viewvc/debian-med/trunk/packages/orthanc/trunk/debian/copyright?view=markup [3] http://anonscm.debian.org/viewvc/debian-med/trunk/packages/orthanc/trunk/debian/rules?view=markup (line 25) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737448: [src:orthanc ] Sourceless file (minified)
On 02/03/2014 12:57 PM, Sebastien Jodogne wrote: Hi Andreas, The problematic files are all *.js files since they are compressed and not to be considered as editable source files. Your task would be to verify, whether there are any *.js files just packaged for Debian (checkout files starting with libjs-* and apt-file search is your friend. You should strip these files from the upstream source. For this I'd recommend using "Files-Excluded" in debian/copyright (see `man uscan`). For those JS files that are not yet packaged I'd recommend to put the real uncompressed source into the dir debian/JS. To have some accepted example you might like to have a look into gnumed-client packaging: http://anonscm.debian.org/viewvc/debian-med/trunk/packages/gnumed-client/trunk/ Thanks for this very helpful clarification. I have however an additional question: During the build process, all the Javascript/HTML/CSS/... resources are integrated into the Orthanc binaries. Is this behavior OK wrt. Debian guidelines? BTW, another related question: How can I bring back the *.js/*.css files into the build folder, where the CMake build script expects them? Am I allowed to create symbolic links in the "override_dh_auto_configure" sections? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737448: [src:orthanc ] Sourceless file (minified)
Hi Andreas, The problematic files are all *.js files since they are compressed and not to be considered as editable source files. Your task would be to verify, whether there are any *.js files just packaged for Debian (checkout files starting with libjs-* and apt-file search is your friend. You should strip these files from the upstream source. For this I'd recommend using "Files-Excluded" in debian/copyright (see `man uscan`). For those JS files that are not yet packaged I'd recommend to put the real uncompressed source into the dir debian/JS. To have some accepted example you might like to have a look into gnumed-client packaging: http://anonscm.debian.org/viewvc/debian-med/trunk/packages/gnumed-client/trunk/ Thanks for this very helpful clarification. I have however an additional question: During the build process, all the Javascript/HTML/CSS/... resources are integrated into the Orthanc binaries. Is this behavior OK wrt. Debian guidelines? Sincerely, Sébastien- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737448: [src:orthanc ] Sourceless file (minified)
Dear Bastien, Please could you be more specific? I have just spotted 2 files without detailed copyright information: * jqtree.css: Part of "tree.jquery.js" by Marco Braak [1]. * slimbox2/slimbox2.css: Part of Slimbox by Christophe Beyls [2]. TIA, Sébastien- [1] http://mbraak.github.io/jqTree/ [2] http://www.digitalia.be/software/slimbox2 On 02/02/2014 10:06 PM, bastien ROUCARIES wrote: Package: src:orthanc Version: 0.7.2-1 Severity: serious User: debian...@lists.debian.org Usertags: source-contains-prebuilt-javascript-object X-Debbugs-CC: ftpmas...@debian.org I could not find the source of a few minified file under OrthancExplorer/libs/ Bastien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736845: orthanc: Undefined symbol: _ZN3fLI7FLAGS_vE
This bug can be fixed by upgrading libgoogle-glog0 to version 0.3.3-1 [1]. The (unreleased) version 0.7.2-2 of the Orthanc package fixes this problem by setting the minimal version of Google Log to 0.3.3 [2]. [1] https://lists.debian.org/debian-med/2014/01/msg00210.html [2] http://anonscm.debian.org/viewvc/debian-med/trunk/packages/orthanc/trunk/debian/control?r1=15411&r2=15861 On 01/27/2014 03:58 PM, Sebastien Jodogne wrote: Package: orthanc Version: 0.7.2-1 Severity: normal When starting Orthanc, a "symbol lookup error" occurs, stating that the symbol "_ZN3fLI7FLAGS_vE" is missing. This prevents Orthanc from starting. This bug was initially reported by Karsten Hilbert [1], who was using a version of libgoogle-glog0 previous to 0.3.3-1. [1] https://lists.debian.org/debian-med/2014/01/msg00206.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736845: orthanc: Undefined symbol: _ZN3fLI7FLAGS_vE
Package: orthanc Version: 0.7.2-1 Severity: normal When starting Orthanc, a "symbol lookup error" occurs, stating that the symbol "_ZN3fLI7FLAGS_vE" is missing. This prevents Orthanc from starting. This bug was initially reported by Karsten Hilbert [1], who was using a version of libgoogle-glog0 previous to 0.3.3-1. [1] https://lists.debian.org/debian-med/2014/01/msg00206.html -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.11-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages orthanc depends on: ii adduser3.113+nmu3 ii dcmtk 3.6.0-15+b1 ii libboost-filesystem1.54.0 1.54.0-3 ii libboost-regex1.54.0 1.54.0-3 ii libboost-system1.54.0 1.54.0-3 ii libboost-thread1.54.0 1.54.0-3 ii libc6 2.17-97 ii libcurl3 7.34.0-1 ii libdcmtk2 3.6.0-15+b1 ii libgcc11:4.8.2-14 ii libgoogle-glog00.3.3-1 ii libjsoncpp00.6.0~rc2-3 ii liblua5.1-05.1.5-5 ii libpng12-0 1.2.49-5 ii libsqlite3-0 3.8.2-1 ii libssl1.0.01.0.1f-1 ii libstdc++6 4.8.2-14 ii libuuid1 2.20.1-5.6 ii zlib1g 1:1.2.8.dfsg-1 orthanc recommends no packages. orthanc suggests no packages. -- Configuration Files: /etc/orthanc/orthanc.json changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728822: Orthanc 0.7.2
Hi Andreas, Following our discussion of this morning [1], I have just updated the DebianMed repository with the newest upstream version of Orthanc (0.7.2) [2]. This release includes an adaptation of the " detect-endian.patch" from Adam Conrad [3], that has also been applied upstream [4]. So, bug #728822 should be fixed with this new release. Please would you kindly check whether everything is OK and upload it to unstable? As it embeds the newly packaged "liborthancclient0.7" shared library, perhaps the ftpmaster could set this upgrade to higher priority. Please let me know if I can further help. Thanks in advance! Regards, Sébastien- [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728822#15 [2] http://anonscm.debian.org/viewvc/debian-med/trunk/packages/orthanc/trunk/debian/ [3] http://anonscm.debian.org/viewvc/debian-med/trunk/packages/orthanc/trunk/debian/patches/check-endianness?revision=15410&view=markup [4] https://code.google.com/p/orthanc/source/diff?spec=svnd76b747aec1b3a46d6d7b4fca51418f0d0dde840&r=d76b747aec1b3a46d6d7b4fca51418f0d0dde840&format=side&path=/UnitTestsSources/main.cpp
Bug#728822: [adcon...@debian.org: Bug#728822: FTBFS on big-endian architectures, patches attached]
Hi Andreas, Could you please confirm that you subscribed the package to get the mails automatically? Alternatively you can (should) subscribe the maintainer mailing list https://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging which also will bring issues of orthanc directly to your attention. Yes, I confirm that I subscribed to both the package and the maintainer mailing list on this morning. I would like now to work on the Orthanc 0.7.2 package, but since it will embed the "liborthancclient0.7" package, I assume this will take several weeks before it is actually available. If we announce to ftpmaster kindly that a package will fix an RC bug this definitely gets priority (I'd volunteer to write the according mail - just ping me). I hope that even in general the new processing will be faster than it used to be until recently. OK, thanks for this interesting information! I work on this topic ASAP. Cheers, Sébastien- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728822: [adcon...@debian.org: Bug#728822: FTBFS on big-endian architectures, patches attached]
Hi Andreas,
Thanks for pointing this patch to me!
The support of big-endian architectures was only included in Orthanc
0.7.1 (released on October 30th).
It was not present in Orthanc 0.6.2, which finally came out of the NEW
queue yesterday. It took about 6 weeks for this version of the Debian
package to come out. I assume this is because of the packaging of the
new component "Orthanc Client".
I will check whether the patch from the Ubuntu team can still improve
the upstream code of Orthanc 0.7.2.
I would like now to work on the Orthanc 0.7.2 package, but since it will
embed the "liborthancclient0.7" package, I assume this will take several
weeks before it is actually available.
Cheers,
Sébastien-
On 12/02/2013 05:47 PM, Andreas Tille wrote:
Hi Sebastien,
I'm not sure whether I just forwarded this patch to you but it seems it
is not fixed yet (at least d/changelog is not closing it). Could you as
upstream please work on this issue because you are considered more
competent than any Debian Med member?
BTW, you can subscribe single packages in the "Package Tracking System"
(PTS) to make sure you will not miss any relevant information.
Kind regards
Andreas.
- Forwarded message from Adam Conrad -
Date: Tue, 05 Nov 2013 14:55:27 -0700
From: Adam Conrad
To: Debian Bug Tracking System
Subject: Bug#728822: FTBFS on big-endian architectures, patches attached
X-Debian-PR-Message: report 728822
X-Debian-PR-Package: orthanc
X-Debian-PR-Keywords: patch
X-Debian-PR-Source: orthanc
Package: orthanc
Version: 0.6.1-1
Severity: serious
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch
In Ubuntu, the attached patch was applied to achieve the following:
* detect-endian.patch: Patch to correctly detect endianness of the
current host architecture, inspired by upstream's incomplete fix.
* fix-endian-png.patch: Patch from upstream to fix PngWriter and
the associated tests on above detected big-endian architectures.
The second patch in the series is a straight backport from upstream
of their PngWriter and testsuite fix, and should be self-evident as
such.
The first patch was heavily inspired by upstream's fix[1] for endian
detection, except that it does it correctly for all arches, instead
of bizarrely assuming that only __powerpc__ is big-endian. Please
forward this one to them as a more complete fix.
If upstream is concerned that might not exist on Win32 (I
have no way of checking this, so don't know), the extra include could
be dropped, as includes on Linux anyway. I just
prefer to be explicit in my includes when using features, as implicit
includes tend to bite you when linux or glibc upstream decide to move
things around. :)
... Adam Conrad
-- System Information:
Debian Release: wheezy/sid
APT prefers trusty-updates
APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500,
'trusty')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.12.0-1-generic (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru orthanc-0.6.1/debian/changelog orthanc-0.6.1/debian/changelog
diff -Nru orthanc-0.6.1/debian/patches/detect-endian.patch
orthanc-0.6.1/debian/patches/detect-endian.patch
--- orthanc-0.6.1/debian/patches/detect-endian.patch1969-12-31
17:00:00.0 -0700
+++ orthanc-0.6.1/debian/patches/detect-endian.patch2013-11-05
14:47:35.0 -0700
@@ -0,0 +1,29 @@
+Description: Detect correct endianness of the host machine
+Author: Adam Conrad
+Forwarded: no
+
+--- orthanc-0.6.1.orig/UnitTests/main.cpp
orthanc-0.6.1/UnitTests/main.cpp
+@@ -3,6 +3,7 @@
+ #include "gtest/gtest.h"
+
+ #include
++#include
+
+ #include "../Core/Compression/ZlibCompressor.h"
+ #include "../Core/DicomFormat/DicomTag.h"
+@@ -479,6 +480,14 @@ TEST(Toolbox, WriteFile)
+ ASSERT_THROW(Toolbox::ReadFile(u, path.c_str()), OrthancException);
+ }
+
++TEST(Toolbox, Endianness)
++{
++#if __BYTE_ORDER == __BIG_ENDIAN
++ ASSERT_EQ(Endianness_Big, Toolbox::DetectEndianness());
++#else // __LITTLE_ENDIAN
++ ASSERT_EQ(Endianness_Little, Toolbox::DetectEndianness());
++#endif
++}
+
+ int main(int argc, char **argv)
+ {
diff -Nru orthanc-0.6.1/debian/patches/fix-endian-png.patch
orthanc-0.6.1/debian/patches/fix-endian-png.patch
--- orthanc-0.6.1/debian/patches/fix-endian-png.patch 1969-12-31
17:00:00.0 -0700
+++ orthanc-0.6.1/debian/patches/fix-endian-png.patch 2013-11-05
14:46:54.0 -0700
@@ -0,0 +1,75 @@
+Description: Fix PngWriter and associated test on big-endian arches
+Author: Adam Conrad
+Origin:
https://code.google.com/p/orthanc/source/detail?r=51892be15618cc934f099bf90c1180215d5778eb
+
+--- orthanc-0.6.1.orig/UnitTests/Png.cpp
orthanc-0.6.1/UnitTests/Png.cpp
+@@ -3,6 +3,7 @@
+ #include
+ #include "../Core/FileFormats/PngReader.h"
+ #include "../Core/FileFormats/PngWriter.h"
++#include
Bug#724947: [orthanc] Non free file
On 09/30/2013 12:23 AM, bastien ROUCARIES wrote: Package: orthanc Severity: serious FPL is non dfsg: it does not allow modification. Please move to non-free/repackage. Dear Bastien, Thanks for your bug report. I am the upstream developer of Orthanc [1]. I am unsure that the FPL you refer to is the same as the FPL of the SHA-1 package by Paul E. Jones that is shipped with Orthanc [2]. Here is the content of the FPL from SHA-1: "Copyright (C) 1998, 2009 Paul E. Jones Freeware Public License (FPL) This software is licensed as "freeware." Permission to distribute this software in source and binary forms, including incorporation into other products, is hereby granted without a fee. THIS SOFTWARE IS PROVIDED 'AS IS' AND WITHOUT ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE AUTHOR SHALL NOT BE HELD LIABLE FOR ANY DAMAGES RESULTING FROM THE USE OF THIS SOFTWARE, EITHER DIRECTLY OR INDIRECTLY, INCLUDING, BUT NOT LIMITED TO, LOSS OF DATA OR DATA BEING RENDERED INACCURATE." This looks to me like a permissive MIT license. I have always thought that this license is compatible with the FSF philosophy. This is evidently not the same license as the so-called Foundation Public License by Bridgethink (also nicknamed FPL), which is indeed incompatible with the Debian Free Software Guidelines [3]. If you do confirm that the FPL of the SHA-1 package is incompatible with Debian policy, I will immediately switch to another library (Orthanc 0.6.2 is to be released this week). I will most probably use boost::uuid if this change is required. Regards, Sébastien- PS: I also forward this mail to the "debian-legal" mailing list. [1] http://packages.debian.org/sid/orthanc [2] https://code.google.com/p/orthanc/source/browse/Resources/sha1/ [3] http://www.libroscope.org/FPL-la-licence-libere-l-argent (in French only) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#716958: orthanc: Preview looks corrupted
Hi Mathieu, For some reason when I upload the attached DICOM file, the preview screen seems very odd. Let me know if you need a snapshot. It seems that the DICOM file was not properly attached to your mail. Please could you send it again? Thanks, Sébastien- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#712038: Missing copyright information
Dear Mathieu, Sorry for missing this copyright information. I have updated the upstream source code of Orthanc: https://code.google.com/p/orthanc/source/browse/OrthancServer/FromDcmtkBridge.cpp I will fix the "debian/copyright" in the next release. Sorry again, Sébastien- On 06/12/2013 02:00 PM, Mathieu Malaterre wrote: Package: orthanc Version: 0.4.0-1 Severity: serious File: orthanc Tags: upstream Neither d/copyright nor upstream COPYING seems to inform that source contains code lifted from another project: $ grep BSD OrthancServer/FromDcmtkBridge.cpp * Mathieu Malaterre (under a BSD license). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698417: Explanation
The preview of this file is not supported from Orthanc Explorer because it is an RGB image. Currently, only uncompressed, graylevel images of 8bpp and 16bpp can be converted to PNG by Orthanc. The support of color images is not (yet) implemented, but it is recorded in Trello [1]. [1] https://trello.com/c/RM37fsl3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677721: Underlinking is also present libdcmnet.so
Hello, I have had similar problems when packaging the Orthanc project [1]. The "libdcmnet.so" shared library has indeed undefined symbols that are defined in the "liboflog.so" and in the "libwrap.so" shared libraries, but "libdcmnet.so" does not state that is depends on wrap and oflog. Here is a command-line session on Debian sid that shows up this problem: > jodogne@unstable:~$ nm -D -C /usr/lib/libdcmnet.so | grep log4cplus U log4cplus::Logger::addAppender(log4cplus::helpers::SharedObjectPtr) U log4cplus::Logger::getAppender(OFString const&) U log4cplus::Logger::removeAppender(log4cplus::helpers::SharedObjectPtr) U log4cplus::Logger::removeAppender(OFString const&) U log4cplus::Logger::getAllAppenders() U log4cplus::Logger::removeAllAppenders() U log4cplus::Logger::Logger(log4cplus::Logger const&) U log4cplus::Logger::~Logger() U log4cplus::Logger::isEnabledFor(int) const U log4cplus::Logger::forcedLog(int, OFString const&, char const*, int, char const*) const U typeinfo for log4cplus::Logger jodogne@unstable:~$ ldd /usr/lib/libdcmnet.so | grep oflog jodogne@unstable:~$ nm -C -D /usr/lib/libdcmnet.so | grep request_init U request_init jodogne@unstable:~$ ldd /usr/lib/libdcmnet.so | grep wrap jodogne@unstable:~$ < The "log4cplus::" stuff is defined in oflog, and the "request_init" stuff is defined in wrap. I think that there is also a missing dependency on ofstd somewhere. Note that the same problem applies to Debian squeeze. Cheers, Sébastien- [1] http://lists.debian.org/debian-med/2012/10/msg7.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689041: RFS: orthanc/0.2.1-3 [ITP] -- Lightweight, RESTful DICOM server for healthcare and medical research
Dear all, Have you thought of maintaining your package within the debian-med umbrella org ? http://www.debian.org/devel/debian-med/ Just back from vacation I read your conversation about orthanc packaging. Besides the obvious helpful technical hints I would like to come back to the initial hint from Mathieu to join the Debian Med team. I have just uploaded the source code for the Debian packaging of Orthanc [1] to the Subversion repository of the Debian Med project [2]. I have not been able to append Orthanc to the "imaging" task of the debian-med Blends repository [3], presumably because of user restrictions. Here is a tentative description for Orthanc in Debian Med tasks: >>>> Depends: orthanc Homepage: https://code.google.com/p/orthanc/ WNPP: 689029 Responsible: Sebastien Jodogne License: GPL Pkg-Description: RESTful DICOM server for healthcare and medical research Orthanc aims at providing a simple, yet powerful standalone DICOM server. Orthanc can turn any computer running Windows or Linux into a DICOM store (in other words, a mini-PACS system). Its architecture is lightweight, meaning that no complex database administration is required, nor the installation of third-party dependencies. . What makes Orthanc unique is the fact that it provides a RESTful API. Thanks to this major feature, it is possible to drive Orthanc from any computer language. The DICOM tags of the stored medical images can be downloaded in the JSON file format. Furthermore, standard PNG images can be generated on-the-fly from the DICOM instances by Orthanc. . Orthanc lets its users focus on the content of the DICOM files, hiding the complexity of the DICOM format and of the DICOM protocol. <<<< Could someone explain how I could further improve the package? I thank you much in advance! Cheers, Sébastien- [1] https://code.google.com/p/orthanc/ [2] http://anonscm.debian.org/viewvc/debian-med/trunk/packages/orthanc/ [3] http://debian-med.alioth.debian.org/tasks/imaging -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689041: RFS: orthanc/0.2.1-3 [ITP] -- Lightweight, RESTful DICOM server for healthcare and medical research
Hi Andreas, Have you thought of maintaining your package within the debian-med umbrella org ? http://www.debian.org/devel/debian-med/ Just back from vacation I read your conversation about orthanc packaging. Besides the obvious helpful technical hints I would like to come back to the initial hint from Mathieu to join the Debian Med team. [...] To learn about the workflow in Debian Med team you might like to read our policy document[1]. Feel free to ask if you have some remaining questions. Thank for your suggestion! I have successfully applied for membership to the Debian-Med project. It seems that I will not have write access to the Subversion repository before tomorrow [1]. As soon as I am able to sync against Subversion, I will try and upload the source code of the Orthanc package to Debian-Med. Regards, Sébastien- [1] http://wiki.debian.org/Alioth/SSH#A..._and_I.27ve_only_recently_been_added_to_a_project -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689041: Re: Orthanc
Hello Mathieu, I have uploaded another version of the package that should fix your comments: http://mentors.debian.net/debian/pool/main/o/orthanc/orthanc_0.2.2-6.dsc 1. $ man -l -k docs/orthanc.1 docs/orthanc.1: nothing appropriate. You can use help2man to quickly generate a proper man page. I now use help2man. Technically it would be nice to use DEP3 for patch, but I assume 'upstream' is aware of those ... I have included the DEP3 required fields. Thanks again, Sébastien- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689041: Re: Orthanc
Dear Gregor, * why libcurl4-gnutls-dev | libcurl4-nss-dev | libcurl4-openssl-dev ? shouldn't that be something simplier like libcurl4-dev ? libcurl-dev ? libcurl-ssl-dev ? If I use "libcurl4-dev", "libcurl-dev" or "libcurl-ssl-dev", I obtain the following Lintian warning: http://lintian.debian.org/tags/virtual-package-depends-without-real-package-depends.html For this reason, I have preferred to keep my explicit enumeration. An alternative would be to use "libcurl4-gnutls-dev | libcurl4-dev". Thank for your reply! I have just uploaded another version of the package with your suggested improvement: http://mentors.debian.net/debian/pool/main/o/orthanc/orthanc_0.2.2-3.dsc Sébastien- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689041: Re: Orthanc
Dear Mathieu, Many thanks for your feedback. I have just uploaded a new version of the Orthanc package: http://mentors.debian.net/package/orthanc http://mentors.debian.net/debian/pool/main/o/orthanc/orthanc_0.2.2-1.dsc Much better indeed ! Some comments below: I think I have successfully implemented almost all your helpful comments in the new version of the package: http://mentors.debian.net/package/orthanc http://mentors.debian.net/debian/pool/main/o/orthanc/orthanc_0.2.2-2.dsc In particular, I now dynamically link against SQLite and JsonCpp, and I have enriched the copyright notice. However, the two following improvements you have noticed have not been fixed: * why libcurl4-gnutls-dev | libcurl4-nss-dev | libcurl4-openssl-dev ? shouldn't that be something simplier like libcurl4-dev ? libcurl-dev ? libcurl-ssl-dev ? If I use "libcurl4-dev", "libcurl-dev" or "libcurl-ssl-dev", I obtain the following Lintian warning: http://lintian.debian.org/tags/virtual-package-depends-without-real-package-depends.html For this reason, I have preferred to keep my explicit enumeration. * why use oflog and libwrap ? They are not used: ... dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/orthanc/usr/bin/orthanc was not linked against libwrap.so.0 (it uses none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/orthanc/usr/bin/orthanc was not linked against liboflog.so.2 (it uses none of the library's symbols) ... Actually, I think this is a problem in the libdcmtk2-dev package. For instance, when I dump the symbols of the "dcmnet.so" file to look for the logging facilities, I get the following: > jodogne@unstable:~$ nm -D -C /usr/lib/libdcmnet.so | grep log4cplus U log4cplus::Logger::addAppender(log4cplus::helpers::SharedObjectPtr) U log4cplus::Logger::getAppender(OFString const&) U log4cplus::Logger::removeAppender(log4cplus::helpers::SharedObjectPtr) U log4cplus::Logger::removeAppender(OFString const&) U log4cplus::Logger::getAllAppenders() U log4cplus::Logger::removeAllAppenders() U log4cplus::Logger::Logger(log4cplus::Logger const&) U log4cplus::Logger::~Logger() U log4cplus::Logger::isEnabledFor(int) const U log4cplus::Logger::forcedLog(int, OFString const&, char const*, int, char const*) const U typeinfo for log4cplus::Logger < But, the "libdcmnet.so" does not explicitly depend on the "liboflog.so" library that implements these symbols: > jodogne@unstable:~$ ldd /usr/lib/libdcmnet.so | grep oflog jodogne@unstable:~$ < For this reason, I am obliged to link against "oflog", otherwise I get a problem at the linking stage. The same problem appears with the "wrap" library that is also implicitly required by "libdcmnet.so" : > jodogne@unstable:~$ nm -C -D /usr/lib/libdcmnet.so | grep request_init U request_init jodogne@unstable:~$ ldd /usr/lib/libdcmnet.so | grep wrap jodogne@unstable:~$ < Note that this problem is also present in the Debian Squeeze and Ubuntu 11.10 distributions. I don't think I can fix this problem by myself. Is there any other improvement I can make to the Orthanc package? Thanks again, Sébastien- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689041: Re: Orthanc
Salut Mathieu, Many thanks for your feedback. I have just uploaded a new version of the Orthanc package: http://mentors.debian.net/package/orthanc http://mentors.debian.net/debian/pool/main/o/orthanc/orthanc_0.2.2-1.dsc The binaries now dynamically link against the versions of DCMTK and Boost that are shipped with Debian. Furthermore, no package is downloaded from Internet anymore. Regards, Sébastien- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689041: Orthanc
Dear Debian Med contributors, I would like to bring to your attention the Orthanc software, which is currently developed at the CHU of Liège (Belgium). As previously pointed out by Mathieu Malaterre in this mailing list, I am feeling that this project could be of interest to the Debian Med project. In a nutshell, Orthanc is a lightweight service that can easily turn any Linux box into a standalone DICOM Store without complex administrative task. The content of the DICOM Store is accessible through a Web-based GUI. The content of Orthanc is also accessible through a RESTful API, which allows easy DICOM scripting from most computer languages. Orthanc is built upon the networking facilities of DCMTK. The homepage of Orthanc can be found at the following URL: https://code.google.com/p/orthanc/ Perhaps Orthanc would be an interesting candidate for inclusion into the Debian Med Imaging packages: http://debian-med.alioth.debian.org/tasks/imaging A Debian package has already been prepared at the following location and is subject to the Debian RFS #689041: http://mentors.debian.net/package/orthanc I hope you will find this information useful and I will be pleased to answer any question about Orthanc. Regards, Sébastien Jodogne- -- Sébastien Jodogne, PhD. Medical Imaging Engineer Radiotherapy, Medical Imaging and Nuclear Medicine services C.H.U. - SART TILMAN - B35 BAT. T1-3 RADIOTHERAPIE 4000 Liège BELGIUM Mail: s.jodo...@chu.ulg.ac.be -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689029: ITP: orthanc -- A lightweight, RESTful DICOM server for healthcare and medical research
Package: wnpp Severity: wishlist Owner: Sebastien Jodogne * Package name: orthanc Version : 0.2.1 Upstream Author : Sebastien Jodogne * URL : https://code.google.com/p/orthanc/ * License : GPL Programming Lang: C++ Description : A lightweight, RESTful DICOM server for healthcare and medical research -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
