Re: [Debian-med-packaging] Bug#1062404: orthanc-python: flaky autopkgtest: Test failed with

[Sébastien Jodogne]

Hello again,

On 3/30/24 15:04, Nilesh Patra wrote:

I have just uploaded it:
https://salsa.debian.org/med-team/orthanc-python/-/commit/3cdc765442ab3fce9148c33ba865467983b11e0b

Actually, the patch was more of a local workaround based on your system 
configuration and should
stay the way it was for debci based workers/lxc backend. With that change the 
autopkgtest job fails[1]
and that's a bad sign 


OK, fine, I've just removed the patch from the package. I'll manually 
reapply it on my local machine if needed.


Best,
Sébastien-

Re: [Debian-med-packaging] Bug#1062404: orthanc-python: flaky autopkgtest: Test failed with

[Sébastien Jodogne]

Now, the next problem is: The test always succeeds on my standard amd64 
architecture. Despite many attempts, I am totally unable to reproduce 
#1062404.


@Paul: How could I reproduce the issue?

@Nilesh: Shouldn't this test simply be disabled?


OK, I think I have finally found the culprit.

This is most probably because the unit test doesn't properly test 
whether Orthanc has finalized its startup. Indeed, instead of testing 
the existence of the "orthanc" process, one has to wait until the REST 
API of Orthanc is actually available.


I have just committed the fix:
https://salsa.debian.org/med-team/orthanc-python/-/commit/9101662e09d956886da7394bacbb7e81d9cb511a

I am now working on a new release that should hopefully close this 
issue. Do not hesitate to re-open the issue if my fix proves to be 
insufficient.


Kind Regards,
Sébastien-

Re: [Debian-med-packaging] Bug#1062404: orthanc-python: flaky autopkgtest: Test failed with

[Sébastien Jodogne]

Hi Nilesh,


For some reason, this is not taking needs-sudo restriction well. Can you try 
once with this
patch (no need to re-compile) and let me know if that helps?

diff --git a/debian/tests/control b/debian/tests/control
index 5e8c44d..4f9b12a 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,3 +1,3 @@
  Tests: run-unit-test
  Depends: @, python3, orthanc, curl, libcurl4, orthanc-python, procps
-Restrictions: needs-sudo, allow-stderr, isolation-container
+Restrictions: allow-stderr


Wonderful! I confirm that with this patch, I am able to run autopkgtest 
as follows:


$ sudo autopkgtest -B ../build-area/orthanc-python_4.1+ds-3_amd64.deb -- 
null


I have just uploaded it:
https://salsa.debian.org/med-team/orthanc-python/-/commit/3cdc765442ab3fce9148c33ba865467983b11e0b


Now, the next problem is: The test always succeeds on my standard amd64 
architecture. Despite many attempts, I am totally unable to reproduce 
#1062404.


@Paul: How could I reproduce the issue?

@Nilesh: Shouldn't this test simply be disabled?

Kind Regards,
Sébastien-

Re: [Debian-med-packaging] Bug#1062404: orthanc-python: flaky autopkgtest: Test failed with

[Sébastien Jodogne]

Dear Nilesh,

Thanks for your so fast support!

On 3/30/24 12:41, Nilesh Patra wrote:

Once compilation is done, how can I execute autopkgtest? I have tried
multiple variations, including the most basic:

$ sudo autopkgtest . -- null
$ sudo autopkgtest ../build-area/orthanc-python_4.1+ds-2_amd64.changes --
null


This should work I suppose, in an unstable system.
I however pass in the .deb instead of the .changes file.

This is the command I use incase that helps you:

$ sudo autopkgtest -B ../*.deb -- schroot unstable-amd64-sbuild

You could use `-- null` if you don't use a schroot.

If this still does not work, can you share the error that you see?


In all of those commands (including yours, as well as if using ".deb" 
instead of ".changes"), I always get the attached log.


The actual test seems to never be executed: The autopkgtest command 
always stops with the "Reading package lists...". Nothing more happens.


Regards,
Sébastien-$ sudo autopkgtest ../build-area/orthanc-python_4.1+ds-2_amd64.deb -- null
autopkgtest [12:47:42]: starting date and time: 2024-03-30 12:47:42+0100
autopkgtest [12:47:42]: version 5.33
autopkgtest [12:47:42]: host debian-unstable; command line: 
/usr/bin/autopkgtest ../build-area/orthanc-python_4.1+ds-2_amd64.deb -- null
autopkgtest [12:47:42]: testbed dpkg architecture: amd64
autopkgtest [12:47:42]: testbed apt version: 2.7.14
autopkgtest [12:47:42]: testbed running kernel: Linux 6.7.9-amd64 #1 SMP 
PREEMPT_DYNAMIC Debian 6.7.9-2 (2024-03-13)
autopkgtest [12:47:42]:  unbuilt-tree .
autopkgtest [12:47:42]: testing package orthanc-python version 4.1+ds-2
autopkgtest [12:47:42]: build not needed
autopkgtest [12:47:42]: test run-unit-test: preparing testbed
Get:1 file:/tmp/autopkgtest.I5zY18/binaries  InRelease
Ign:1 file:/tmp/autopkgtest.I5zY18/binaries  InRelease
Get:2 file:/tmp/autopkgtest.I5zY18/binaries  Release [816 B]
Get:2 file:/tmp/autopkgtest.I5zY18/binaries  Release [816 B]
Get:3 file:/tmp/autopkgtest.I5zY18/binaries  Release.gpg
Ign:3 file:/tmp/autopkgtest.I5zY18/binaries  Release.gpg
Get:4 file:/tmp/autopkgtest.I5zY18/binaries  Packages [1,379 B]
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/193 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 file:/tmp/autopkgtest.I5zY18/binaries  orthanc-python 4.1+ds-2 [193 kB]
(Reading database ... 196769 files and directories currently installed.)
Preparing to unpack .../binaries/./orthanc-python.deb ...
Unpacking orthanc-python (4.1+ds-2) over (4.1+ds-2) ...
Setting up orthanc-python (4.1+ds-2) ...
Processing triggers for libc-bin (2.37-15.1) ...
Processing triggers for orthanc (1.12.3+dfsg-1) ...
orthanc-restart-trigger: restarting the Orthanc service
W: --force-yes is deprecated, use one of the options starting with --allow 
instead.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'autopkgtest-satdep' instead of 
'/tmp/autopkgtest.I5zY18/2-autopkgtest-satdep.deb'
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
The following NEW packages will be installed:
  autopkgtest-satdep
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/736 B of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 /tmp/autopkgtest.I5zY18/2-autopkgtest-satdep.deb autopkgtest-satdep amd64 
0 [736 B]
Selecting previously unselected package autopkgtest-satdep.
(Reading database ... 196769 files and directories currently installed.)
Preparing to unpack .../2-autopkgtest-satdep.deb ...
Unpacking autopkgtest-satdep (0) ...
Setting up autopkgtest-satdep (0) ...
(Reading database ... 196769 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
run-unit-testSKIP Cannot enable needs-sudo restriction: no ordinary 
user available
autopkgtest [12:47:49]:  summary
run-unit-testSKIP Cannot enable needs-sudo restriction: no ordinary 
user available
autopkgtest [12:47:49]: Binaries: resetting testbed apt configuration
Hit:1 http://deb.debian.org/debian unstable InRelease
Reading package lists...

Re: [Debian-med-packaging] Bug#1062404: orthanc-python: flaky autopkgtest: Test failed with

[Sébastien Jodogne]

Hello,

On 2/1/24 17:36, Nilesh Patra wrote:

On Thu, Feb 01, 2024 at 01:55:21PM +0100, Sébastien Jodogne wrote:

Even if I'm tagged as the maintainer of "orthanc-python", I don't know
how autopkgtest/flaky works (I haven't implemented such tests by
myself).


This is the script that runs for tests:


https://salsa.debian.org/med-team/orthanc-python/-/blob/master/debian/tests/run-unit-test?ref_type=heads

This is a basic script that should work and did work at least locally -- note that I only 
"sponsored"
an upload for this package and did not delve very deep into the working detaiks.


Please, I really need help here. Despite hours of trial and error, I'm 
still unable to understand how autopkgtest works. Unfortunately, I can't 
find by myself a Debian tutorial on how to run such tests.


At time point, I build the package using the following command line:

$ gbp buildpackage -us -uc --git-pristine-tar 
--git-export-dir=../build-area/ -j4


Once compilation is done, how can I execute autopkgtest? I have tried 
multiple variations, including the most basic:


$ sudo autopkgtest . -- null
$ sudo autopkgtest ../build-area/orthanc-python_4.1+ds-2_amd64.changes 
-- null


as well as the use of qemu:

$ sudo autopkgtest-build-qemu unstable /var/tmp/autopkgtest-unstable.img
$ sudo autopkgtest ../build-area/orthanc-python_4.1+ds-2_amd64.changes 
-- qemu /var/tmp/autopkgtest-unstable.img


Could someone indicate me the proper way of calling autopkgtest so that 
I can debug the test that was sponsored?


Kind Regards,
Sébastien-

Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)

[Sébastien Jodogne]

Dear Emmanuele and Mathieu,

On 3/19/24 08:51, Mathieu Malaterre wrote:

On Tue, Mar 19, 2024 at 8:44 AM Emanuele Rocca  wrote:


Hi,

On 2024-03-19 06:24, Sébastien Jodogne wrote:

Because of bug #1060104, a large majority of the packages related to
medical imaging have just disappeared from Debian Unstable.

But, if I correctly understand #1060104, it is specific to one single
platform (armel).


Indeed, and there is a simple fix too, which has been uploaded to
experimental only so far:
https://salsa.debian.org/med-team/dcmtk/-/commit/42583dfe9fd344a63cdbc278268d4176d4a22ec4

Mathieu (or someone else from debian-med), could you please apply that
to unstable as well? It seems that with the current state of unstable
the transition will take a while anyways.


I will be away from any Debian tasks for at least another month
unfortunately. The patch was suggested by an armel porter so I believe
this is the right thing to do.


Worth pointing out that right now dcmtk cannot be built in sid/armel due
to a missing build depend, namely graphviz. It seems worth applying the
fix to unstable anyways so that it does not fall through the cracks, and
we can schedule a binNMU later when graphviz is available again.


I could try to upload this patch by myself to unstable. Unfortunately, 
I'm not an uploader of the dcmtk package, so an intervention from a 
Debian Developer is required to give me the proper access rights:

https://tracker.debian.org/pkg/dcmtk

Kind Regards,
Sébastien-

Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)

[Sébastien Jodogne]

Dear all,

Because of bug #1060104, a large majority of the packages related to 
medical imaging have just disappeared from Debian Unstable.

But, if I correctly understand #1060104, it is specific to one single 
platform (armel).

My question is: Rather than penalizing all platforms (including the most 
common arm64) and thus a huge number of users working on healthcare 
application, couldn't a temporary measure be to remove the armel builds?

Best Regards,
Sébastien-


On Sat, 24 Feb 2024 10:03:07 +0100 Sebastian Ramacher 
 wrote:
> Control: severity -1 serious
> 
> On 2024-01-18 13:38:20 +0100, Mathieu Malaterre wrote:
> > Control: severity -1 important
> > 
> > On Mon, Jan 15, 2024 at 1:49 PM Emanuele Rocca  wrote:
> > [...]
> > > For this reason I would
> > > suggest to disable stackclash on the armel build of dcmtk (just like you
> > > did in experimental) to make sure the package builds properly again, but
> > > keep #1060104 open at a lower severity so that we don't lose track of
> > > this.
> > 
> > Done ! Thanks
> 
> dcmtk is still failing to build on unstable buildds, so raising the
> severity again to serious. Please only lower the severity once the
> package builds again.
> 
> Cheers
> -- 
> Sebastian Ramacher

Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)

[Sébastien Jodogne]

Dear all,

Because of bug #1060104, a large majority of the packages related to 
medical imaging have just disappeared from Debian Unstable.


But, if I correctly understand #1060104, it is specific to one single 
platform (armel).


My question is: Rather than penalizing all platforms (including the most 
common arm64) and thus a huge number of users working on healthcare 
application, couldn't a temporary measure be to remove the armel builds?


Note that as far as I'm concerned, I cannot help on armel.

Best Regards,
Sébastien-


On Sat, 24 Feb 2024 10:03:07 +0100 Sebastian Ramacher 
 wrote:

Control: severity -1 serious

On 2024-01-18 13:38:20 +0100, Mathieu Malaterre wrote:
> Control: severity -1 important
> 
> On Mon, Jan 15, 2024 at 1:49 PM Emanuele Rocca  wrote:

> [...]
> > For this reason I would
> > suggest to disable stackclash on the armel build of dcmtk (just like you
> > did in experimental) to make sure the package builds properly again, but
> > keep #1060104 open at a lower severity so that we don't lose track of
> > this.
> 
> Done ! Thanks


dcmtk is still failing to build on unstable buildds, so raising the
severity again to serious. Please only lower the severity once the
package builds again.

Cheers
--
Sebastian Ramacher

Re: [Debian-med-packaging] Bug#1062404: orthanc-python: flaky autopkgtest: Test failed with

[Sébastien Jodogne]

Hello,

Even if I'm tagged as the maintainer of "orthanc-python", I don't know
how autopkgtest/flaky works (I haven't implemented such tests by
myself). I consequently forward your message to the Debian Med mailing
list, as I cannot help on this bug by myself.

Regards,
Sébastien-

> I looked at the results of the autopkgtest of your package. I noticed
> that it regularly fails on several architectures because it currently
> blocks glibc. Unfortunately the log seems to be missing the actual
> problem as it ends with:
>   45s W0131 12:12:35.955520 MAIN FromDcmtkBridge.cpp:382]
> Loading external DICOM dictionary: "/usr/share/libdcmtk17/private.dic"
>   45s Test failed with
>
> Because the unstable-to-testing migration software now blocks on
> regressions in testing, flaky tests, i.e. tests that flip between
> passing and failing without changes to the list of installed packages,
> are causing people unrelated to your package to spend time on these
> tests.
>
> Don't hesitate to reach out if you need help and some more information
> from our infrastructure.

Re: Adding autopkgtest to Orthanc-python

[Sébastien Jodogne]

Hello,

On 11/4/23 11:53, Nilesh Patra wrote:

I see -- but this seems a little counter-intuitive, no? orthanc-python
installs files in /etc/orthanc/ but by what you said above the plugins
should be installed only in /usr/share/orthanc/plugins/ to be working
(along with a bunch of .so files) - is that correct?


Actually, the orthanc-python package does install files in the 
"/usr/share/orthanc/plugins" and "/usr/lib/orthanc/" folders, as can be 
seen in the filelist:

https://packages.debian.org/sid/amd64/orthanc-python/filelist

The package only installs its configuration files in the "/etc/orthanc/" 
folder.



Tests pass after manually symlinking the said `.so` file but I am not
sure if this is a sensible thing to do for tests, It'd be great if you
could comment on that.


I cannot provide any insight about this question, because I'm not 
familiar at all with autopkgtest.


Kind Regards,
Sébastien-

Re: Adding autopkgtest to Orthanc-python

[Sébastien Jodogne]

Hello,


I tried doing something similar however the test still seems to fail.
The failing job can be found at[3].
[3] https://salsa.debian.org/med-team/orthanc-python/-/jobs/4887512


The log file of Orthanc indicates that the Python plugin is simply not 
loaded:


>
I1104 10:12:22.947781 PluginsManager.cpp:280] (plugins) Scanning folder 
./. for plugins
W1104 10:12:22.947999 OrthancInitialization.cpp:420] SQLite index 
directory: "./OrthancStorage"

<

The folder "./." should contain the "libOrthancPlugin.so" shared 
library, which is visibly not the case, otherwise you would see the 
following lines in the logs:


>
I1104 11:32:23.337849 PluginsManager.cpp:303] (plugins) Found a shared 
library: "./libOrthancPython.so"
W1104 11:32:23.342062 PluginsManager.cpp:261] Registering plugin 
'python' (version mainline)

W1104 11:32:23.342093 PluginsManager.cpp:157] Python plugin is initializing
<



Seems to me the reason is that the route to /toto is still not present
and the offending line is _probably_

| W1104 10:12:22.974692 main.cpp:1184] REST API cannot write to the file system.

But I am not really sure since I see the error even if change the test
dir to a dir with write permissions from everyone.


No, this warning is unrelated and can be safely ignored in this context.

Best,
Sébastien-

Re: Adding autopkgtest to Orthanc-python

[Sébastien Jodogne]

Dear all,

This error indicates that two instances of Orthanc are running at the 
same time, most probably because the "orthanc" Debian service is not 
stopped at the beginning of the test by autopkgtests.


I indeed do not see any call to "systemctl stop orthanc" in the main 
script "debian/tests/run-unit-test" [1], is this expected?


I also don't understand how "debian/tests/run-unit-test" starts Orthanc. 
By using "Orthanc ./configuration.json --verbose", the script will not 
progress until Orthanc is manually stopped. From my understanding, 
Orthanc should instead be launched in the background (i.e., by adding an 
ampersand).


Furthermore, before making a call to "http://localhost:8042/toto; (which 
is added by the Python plugin), the test script should wait until 
Orthanc is actually started. This can be tested by an (infinite) loop 
testing whether the Orthanc PID is still existent, while waiting until 
"http://localhost:8042/system; answers (this is a route that is built in 
Orthanc).


However, as stated in another thread [2], I have strictly no experience 
with autopkgtests, so I cannot help readily here.


Kind Regards,
Sébastien-


[1] 
https://salsa.debian.org/med-team/orthanc-python/-/commit/9e751a67614e90d383956f400906ce8121bcfc81

[2] https://lists.debian.org/debian-med/2023/10/msg00017.html



On 20/10/23 18:28, Aaron M. Ucko wrote:

Andreas Tille  writes:


I have no idea what this might mean.  Could you have a look at the
test?  I also realised that you are installing


There's a more specific error a few lines up:

   E1020 09:35:18.908283 OrthancException.cpp:61] The TCP port of the DICOM 
server is privileged or already in use:  (port = 4242) cannot create network: 
TCP Initialization Error: Address already in use

I don't know what else would be listening there, though, or if the
actual issue is that the container doesn't allow listening for network
connections at all, though in that case I might have expected a more
appropriate error code.

Re: Orthanc Integration Test using Orthanc-wsi

[Sébastien Jodogne]

Dear Israel,

Thanks for your work on this.

Please however could you explain me how to execute autopkgtests on my 
development Debian, without having to recompile the package from scratch 
everytime I try to modify the "debian/test/*" files?


I have strictly no experience with autopkgtests, and I don't have much 
time to gather all the pieces by myself.


Kind Regards,
Sébastien-


On 20/10/23 15:42, Komolehin Israel wrote:

Hi Sebastian,

I created autopkgtests for Orthanc and Orthanc-wsi. Orthanc has been uploaded 
to unstable however Is it fine to update orthanc package’s autopkgtest with an 
integration test using orthanc-wsi ?

Regards,
Israel

Re: Bug filled against an old version of a package

[Sébastien Jodogne]

Dear Joost,

On 18/08/23 17:27, Joost van Baal-Ilić wrote:

On Fri, Aug 18, 2023 at 04:35:27PM +0200, Sébastien Jodogne wrote:

[...]
Please could someone indicate me what I should do in such a situation?
Thanks for any advice!


Just send this explanation to 1041116-cl...@bugs.debian.org.
Adding a pseudo-header indicating the version in which is was
closed would be even better.

HTH, Bye,
Joost


Thanks for your explanation! The bug is now closed:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041116#10

Best,
Sébastien-

Bug filled against an old version of a package

[Sébastien Jodogne]

Dear all,

I have a question regarding the issue #1041116 that is currently opened 
against the "orthanc-postgresql" package:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041116

This bug is filed against the version of the "orthanc-postgresql" 
package version that corresponds the "stable" Debian distribution (i.e. 
orthanc-postgresql/4.0-7).


But, this issue was fixed in the "orthanc-postgresql/5.0+dfsg-1" version 
that was uploaded a month ago. I have just checked that the FTBFS is not 
present anymore with this new version in the "unstable" distribution.


Please could someone indicate me what I should do in such a situation? 
Thanks for any advice!


Best,
Sébastien-

Re: Fwd: civetweb_1.15+dfsg-5_source.changes REJECTED

[Sébastien Jodogne]

Dear Andreas,


For whatever reason the pristine-tar information does not match the
upstream source tarball.  My way to solve it is to re-import the
tarball I get via

 apt source civetweb


Thanks, that worked! But indeed, it is not relevant anymore since your 
update to civetweb 1.16 :-)



I admit I'm a bit scared about the need to update the symbols file again.
For my not very well educated eyes we do not need to bump SOVERSION -
but I'd like to have some review here.


From my understanding, the issue here is that we have 2 shared 
libraries: "libcivetweb-cpp.so" (from C++) and "libcivetweb.so" (from C).


But, according to the following page, "For C++ libraries it is often 
better not to ship symbols files":

https://wiki.debian.org/UsingSymbolsFiles#C.2B-.2B-_libraries

This stems from the fact that the names of the binary C++ symbols will 
for instance change by just upgrading g++. This contrasts with the C 
shared library, for which the ABI is standardized.


As far as I'm concerned, I would consequently tend to consider that 
"libcivetweb1.symbols.amd64" should only contain the symbols of 
"libcivetweb.so" (i.e. not those of "libcivetweb-cpp.so").


Furthermore, from my understanding, the suffix of the symbols from 
"libcivetweb.so" should only contain "1", not "1.15" or "1.16", because 
of the stability of the C ABI, and because it is OK to add new symbols, 
while removing symbols should be prohibited. This explains my following 
changeset, where "1.15" was replaced by "1" for all the functions 
beginning with "mg_":

https://salsa.debian.org/med-team/civetweb/-/commit/4be6bc58d7c7f5477b34b9ad4bffdad7ad0cac3c

Unfortunately, I was unable to find an option to "dpkg-gensymbols" to 
generate one single symbols file describing two shared libraries, but 
with different versions.

So in case you see some issues that take longer to resolve (bumping
SOVERSION means new processing) it might be more sensible to revert the
upstream version to what we had and fix the bug first.


As explained above, I don't think that SOVERSION should be bumped in a C 
library, at least as long as symbols are not removed, and as long as the 
upstream doesn't warn about a breaking change in the meaning of the 
functions (which is not the case of civetweb).


But I might also be fully wrong with what I explained above...

Regards,
Sébastien-

Re: Fwd: civetweb_1.15+dfsg-5_source.changes REJECTED

[Sébastien Jodogne]

Deal Nilesh,

Thanks for your help!

On 15/07/23 17:35, Nilesh Patra wrote:

On Sat, Jul 15, 2023 at 01:46:57PM +0200, Sébastien Jodogne wrote:

On another topic, it looks like I've been kicked off the
"debian-med-packaging" mailing list, and I'm unable to register back using
my "s.jodo...@orthanc-labs.com" e-mail. Is there currently a known issue on
the Debian mailing lists?


What exactly does "unable to register back" translate to? is it that you
never get the 'subscribe' mail?


I never get the "subscribe" mail, nor any mail from the mailing list 
(though it used to work until the Debian freeze, and I never 
unregistered). Looks like I've been blacklisted.



Do you happen to use gmail with @orthanc-labs.com by any chance? From
your mail headers I got a hint that you use ovh mail and somewhere in
the loop you use a MS server - is that correct?


No, my GMail account is only there to sign the packages, in order to 
hopefully have a long-term address that never gets blacklisted by the GAFAM.


All my activity on the Debian mailing lists uses "@orthanc-labs.com", 
which is indeed a "professional e-mail" offer from OVH. And, 
unfortunately, OVH indeed uses MS Server (to my great disappointment).



gmail has started rejecting emails which do not contain a DKIM signature
or fail their SPF checks. It is likely similar for outlook and other
providers too (alioth subscribe mails are not dkim signed). > Check your spam in case it has your address. If you had ever setup 

login for

https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
then going there to login with your creds and re-subscribing your mail
could help.


I have evidently checked my spam box multiple times, as well as tried to 
unregister/re-register, but this unfortunately didn't help.


The strange thing here is that I seemingly still receive the mails from 
the "Debian Med" list, but not from "Debian Med Packaging".



If not, you'll have to reach out to the list admins.


I will do this.

Best,
Sébastien-

Fwd: civetweb_1.15+dfsg-5_source.changes REJECTED

[Sébastien Jodogne]

Dear all,

I've tried to fix issue #1037603 in the civetweb package:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037603

Unfortunately, my upload has failed with the log below.

Please could you explain me what I should do when facing such a 
situation? Thanks in advance!


On another topic, it looks like I've been kicked off the 
"debian-med-packaging" mailing list, and I'm unable to register back 
using my "s.jodo...@orthanc-labs.com" e-mail. Is there currently a known 
issue on the Debian mailing lists?


Kind Regards,
Sébastien-



-- Forwarded message -
From: *Debian FTP Masters* >

Date: Sat, 15 Jul 2023 at 13:33
Subject: civetweb_1.15+dfsg-5_source.changes REJECTED
To: Sebastien Jodogne >, Debian Med Packaging Team 
>



civetweb_1.15+dfsg-5.dsc: Invalid size hash for 
civetweb_1.15+dfsg.orig.tar.xz:

According to the control file the size hash should be 491292,
but civetweb_1.15+dfsg.orig.tar.xz has 491284.

If you did not include civetweb_1.15+dfsg.orig.tar.xz in your upload, a 
different version

might already be known to the archive software.



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.

Re: Latest version of orthanc fails

[Sébastien Jodogne]

> I did not upgrade, just pushed to Git to prepare for future
> uploads.  I will not upload any orthan* package without your
> confirmation.

Great! Be sure that as soon as a new suitable is available, I'll take
care of the upload.

Sébastien-

Re: Latest version of orthanc fails

[Sébastien Jodogne]

Hi Andreas,

On Mon, 6 Feb 2023 at 08:58, Andreas Tille  wrote:
>
> Hi Sébastian,
>
> I injected the latest version of orthanc into Git but got
>
> CMake Error at cmake_install.cmake:96 (file):
>   file INSTALL cannot find
>   "/build/orthanc-1.11.2+dfsg/BuildServer/libDelayedDeletion.so": No such
>   file or directory.
>
> Any idea how to fix this?

Unfortunately, this was not a good idea to upgrade to this newer
version, as it is not approved yet by myself regarding GNU/Linux
deployments. An approved version is expected soon, in March 2023.

I would highly advise to revert to 1.10.1.

Kind Regards,
Sébastien-

Re: Uscan error for orthanc-wsi

[Sébastien Jodogne]

Hi Andreas,

On 19/01/23 14:25, Andreas Tille wrote:

Hi Sébastien,

Am Thu, Jan 19, 2023 at 02:06:30PM +0100 schrieb Sébastien Jodogne:

I'm trying to get in touch with them. If no solution can be found in a
reasonable amount of time, I'll migrate the downloads onto the servers of my
university for a more sustainable infrastructure.


Thanks a lot for the quick and helpful response


The Web site is now up and running, so uscan should work again:
https://www.orthanc-server.com/browse.php?path=/whole-slide-imaging

Sébastien-

Re: Uscan error for orthanc-wsi

[Sébastien Jodogne]

Dear Andreas,

Thanks for your message. It looks like the sysadmins from Osimis, the 
company that owns the Orthanc Web site, have broken all the downloads of 
Orthanc (not only orthanc-wsi).


I'm trying to get in touch with them. If no solution can be found in a 
reasonable amount of time, I'll migrate the downloads onto the servers 
of my university for a more sustainable infrastructure.


Regards,
Sébastien-


On 19/01/23 13:49, Andreas Tille wrote:

Hi Sebastien,

I realised that the watch file for orthanc-wsi does not work any more.
It points to the web page

https://www.orthanc-server.com/browse.php?path=/whole-slide-imaging

which simply returns

Unable to create the table:

Could you fix this please?

Kind regards
 Andreas.



--
Sébastien Jodogne
Web: https://info.ucl.ac.be/~sjodogne/
Twitter: https://twitter.com/sjodogne

Re: Command line switches for aeskulap

[Sébastien Jodogne]

Hello,

I'm the leader of the Orthanc project that was mentioned by Karsten.

Orthanc comes with the "Stone Web viewer" plugin that provides a free 
and open-source radiology viewer with features similar to those of aeskulap:

https://www.orthanc-server.com/static.php?page=stone-web-viewer

You could suggest the surgeon's to install this viewer on their own 
Microsoft Windows machines using the official Orthanc installers:

https://www.orthanc-server.com/download-windows.php

You could also run Orthanc on a GNU/Linux virtual machine in the cloud, 
then provide an access to the surgeon's office. You can find Debian 
packages for the Stone Web viewer in a standalone Debian repository 
(this is not part of the official Debian distribution yet, because of 
inherent difficulties to package WebAssembly applications):

https://book.orthanc-server.com/users/cookbook.html#obtaining-binaries

Finally, do not hesitate to get in touch with the Orthanc community at 
the following address:

https://groups.google.com/g/orthanc-users

Hope this helps,
Sébastien-


On 12/11/22 01:23, Karsten Hilbert wrote:

Am Fri, Nov 11, 2022 at 09:57:36PM +0100 schrieb Andreas Tille:


Am Fri, Nov 11, 2022 at 07:39:53AM -0800 schrieb L Peter Deutsch:

Dear M. Pipelka and M. Tille,

I found your names and e-mail addresses on the aeskulap man page.

A hospital has provided us with a CD of CT scans in DICOM format that are
essential for my husband's surgery.  The surgeon's staff has been unable to
view them; convert (ImageMagick), dcm2pnm, and dcmj2pnm all produce images
that are gray with only tiny shade variations.  aeskulap produces beautiful
clear images, but the surgeon's office does not run Linux and cannot use
aeskulap.

I have been unable to find any documentation for aeskulap other than a very
short man page.  I could have sworn I saw a man page that gave instructions
for a command line switch that caused aeskulap to write an image file in
some more usable format (PNG, PDF, ...), but I cannot find this page
anywhere now.  Does such documentation exist, and if so, where?


As fas as I remember there were not really any switches.

Discussion was on adding DICOMDIR support to the command line
somehow.

Have you tried importing the images into the Orthanc DICOM
server and re-retrieving images from that as PNG ?

www.orthanc-server.com

There's a Debian package available.

Retrieval can be done with some simple Python.

If you get the images into that, and if you can display them
OK with the integrated browser based viewer, I can try to
help out with some Python code. For starters on that, go
here:


https://github.com/ncqgm/gnumed/blob/master/gnumed/gnumed/client/business/gmDICOM.py

Bast,
Karsten



L Peter Deutsch
(original author of Ghostscript)


Thanks.

--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

Re: Acquiring Dental RVG on Linux

[Sébastien Jodogne]

On 12/10/22 14:22, Karsten Hilbert wrote:

Am Wed, Oct 12, 2022 at 09:08:47AM -0300 schrieb Leonardo M. Ramé:


Good news!, Horos shows the image exactly as the software from Carestream. Now 
it's a matter of looking at their source code.


Ha !  Now *that* is interesting. I am pretty curious as to
what they do ...

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B



Also interested to know the algorithm. This feature might be added to 
Stone Web viewer, as dentistry is also in the scope of the Orthanc project:

https://www.orthanc-server.com/static.php?page=stone-web-viewer

Sébastien-

GNUHealthCon and OrthancCon

[Sébastien Jodogne]

Dear Debian Med community,

I take the liberty of writing this message to inform you that a second 
edition of the joint conference GHCon/OrthancCon will take place in Las 
Palmas de Gran Canaria on November 17-18, 2022.


1- "The GNU Health Conference (GHCon) is an annual conference that 
brings together enthusiasts and developers of the Libre Health & 
Hospital Information System."

https://www.gnuhealthcon.org/2022/

2- "OrthancCon explores the field of free, libre and open-source 
software for medical imaging."

https://www.orthanc-server.com/static.php?page=orthanc-con-2022

Both conferences are free events, and have an open call for abstracts: 
Feel free to contribute!


Kind Regards,
Sébastien-


--
Sébastien Jodogne
Web: https://www.info.ucl.ac.be/~sjodogne/
Twitter: https://twitter.com/sjodogne

Re: Neuroimaging plugin for Orthanc

[Sébastien Jodogne]

Hi Étienne,

On 27/04/22 19:55, Étienne Mollier wrote:

All good to me, you can adjust the d/changelog to target either
"unstable" or "experimental" at your convenience, instead of
"UNRELEASED", and it will be ready for upload.


Great! I have adjusted d/changelog for upload:
https://salsa.debian.org/med-team/orthanc-neuro/-/commit/6c1ab84e5b695ca4f57b30806b0b0ac56e51a441

Have a nice evening,
Thanks again,
Sébastien-

Re: Neuroimaging plugin for Orthanc

[Sébastien Jodogne]

Dear Étienne,

Thank so much for your quick answer and for your kind review!

I think I have fixed all the issues you reported through today's four 
changesets:

https://salsa.debian.org/med-team/orthanc-neuro/-/commits/master

Please let me know if another adjustment must be made before the upload.

Regards,
Sébastien-


On 26/04/22 21:41, Étienne Mollier wrote:

Hi Sébastien,

Sébastien Jodogne, on 2022-04-26:

I've just created a new package that brings support for neuroimaging in
Orthanc (DICOM-to-NIfTI conversion, similarly to dcm2niix):
https://salsa.debian.org/med-team/orthanc-neuro/

Would it be possible for a Debian developer to review this package, and
possibly upload it to NEW? Many thanks in advance!


I had a quick look at your new package and I have few remarks.

d/watch: I would have bumped it to version=4; from quick check,
this seems to be doable without further change to the file.

d/copyright: I expect ftpmaster to raise eyebrows on the
following files under LGPL-3+ but not documented as such:

Resources/Orthanc/CMake/AutoGeneratedCode.cmake
Resources/Orthanc/CMake/Compiler.cmake
Resources/Orthanc/CMake/DownloadOrthancFramework.cmake
Resources/Orthanc/CMake/DownloadPackage.cmake
Resources/Orthanc/CMake/EmbedResources.py
Resources/Orthanc/CMake/GoogleTestConfiguration.cmake
Resources/Orthanc/CMake/WindowsResources.py
Resources/Orthanc/Toolchains/LinuxStandardBaseToolchain.cmake
Resources/Orthanc/Toolchains/MinGW-W64-Toolchain32.cmake
Resources/Orthanc/Toolchains/MinGW-W64-Toolchain64.cmake
Resources/Orthanc/Toolchains/MinGWToolchain.cmake

I get the package-has-unnecessary-activation-of-ldconfig-trigger
lintian warning.  I suppose this may be a side effect of a bug
in debhelper while auto-generating files from d/triggers, but if
you were to have a precise idea of the cause, it would be nice
to fix it or clarify the situation in a comment around a lintian
override.

The package looks otherwise in rather good shape to me.  Once
the d/copyright file is adjusted, I would be happy to sponsor
upload.

Thank you for Orthanc developpement!

Have a nice day,  :)

Neuroimaging plugin for Orthanc

[Sébastien Jodogne]

Dear all,

I've just created a new package that brings support for neuroimaging in 
Orthanc (DICOM-to-NIfTI conversion, similarly to dcm2niix):

https://salsa.debian.org/med-team/orthanc-neuro/

Would it be possible for a Debian developer to review this package, and 
possibly upload it to NEW? Many thanks in advance!


Kind Regards,
Sébastien-

Re: Fwd: [Debian-med-packaging] Bug#1003314: orthanc package: startlimitburst too low

[Sébastien Jodogne]

Thank so much for your pointer to dpkg triggers!

The trigger was added by the following changeset in the main orthanc 
package:

https://salsa.debian.org/med-team/orthanc/-/commit/4ba881a9551b4cba88fb4e278957618380d790c6

I will now update the plugin packages so as they activate this new trigger.

Regards,
Sébastien-



On 14/01/22 14:04, Aaron M. Ucko wrote:

Sébastien Jodogne  writes:


Please could someone indicate how I can modify such a postinst script
so as Orthanc is only restarted once if multiple Orthanc plugins are
installed/upgraded at once?


Please try using dpkg's trigger mechanism, per
/usr/share/doc/dpkg/triggers.txt.gz (and the manpages it cites).


Or should I modify the main "orthanc.service" to set
"StartLimitBurst=10", as proposed by Gerald? But in this case, how to
ensure the compatibility with non-systemd deployments?


Do they even have such limits?  I can't speak for alternatives that were
never the default (such as runit, or upstart if that's still an option),
but I'm fairly certain classic SysV init never attempted to track, let
alone limit, how frequently services restarted.

At any rate, thanks for checking!

Fwd: [Debian-med-packaging] Bug#1003314: orthanc package: startlimitburst too low

[Sébastien Jodogne]

Dear all,

I take the liberty of forwarding this issue to the main Debian Med list, 
as I am unsure about the proper way of solving it.


All the Orthanc plugins now contain a postinst script that is similar to 
the following one:

https://salsa.debian.org/med-team/orthanc-webviewer/-/blob/debian/2.7-6/debian/postinst

The Orthanc service must be restarted in order for the plugin to 
actually get loaded by Orthanc.


Please could someone indicate how I can modify such a postinst script so 
as Orthanc is only restarted once if multiple Orthanc plugins are 
installed/upgraded at once?


Or should I modify the main "orthanc.service" to set 
"StartLimitBurst=10", as proposed by Gerald? But in this case, how to 
ensure the compatibility with non-systemd deployments?


Finally, note that I won't have time to maintain a backport to Debian 11.

Regards,
Sébastien-


 Forwarded Message 
Subject: [Debian-med-packaging] Bug#1003314: orthanc package: 
startlimitburst too low

Resent-Date: Sat, 8 Jan 2022 01:39:02 +
Resent-From: Gerald Wiese 
Resent-To: debian-bugs-d...@lists.debian.org
Resent-CC: Debian Med Packaging Team 


Date: Sat, 8 Jan 2022 02:35:38 +0100
From: Gerald Wiese 
Reply-To: Gerald Wiese , 1003...@bugs.debian.org
To: sub...@bugs.debian.org

Package: orthanc

Version: 1.9.2.+really1.9.1+dfsg-1

When installing Orthanc inside my Ansible scripts the following problem 
occurs: Every package orthanc-* triggers a
systemd service restart and if there are a couple of orthanc extensions 
the StartLimitBurst is reached. This can be

fixed by including "StartLimitBurst=10" in orthanc.service.


Reproduce:

$ sudo apt install -y git ansible

$ ansible-galaxy collection install community.general community.crypto

$ git clone 
https://gitlab.com/geraldwiese/gnuhealth-automatic-deployment.git


$ cd gnuhealth-automatic-deployment/

In orthanc/installation.yml delete lines 1-12 in order to disable my 
workaround


In orthanc/vault: set 'vault_ssh_user' to OS user and 
'use_ssh_pw_for_sudo' to false


$ ansible-playbook orthanc.yml -c local -K


Unfortunately I can't copy the error message from the VM but the 
important part is probably "orthanc.service: Start

request repeated too quickly".

Running Debian 11 and Ansible 2.10.8


This problem does not occure on Ubuntu, but there the version of orthanc 
seems to be 1.5.8+dfsg-2ubuntu6


Could you please tell me if I am overlooking something or if I'm right 
and it's possible to increase the StartLimitBurst

in the shipped files?


Kind regards

Gerald

___
Debian-med-packaging mailing list
debian-med-packag...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

Re: Static linking without using a Built-Using attribute

[Sébastien Jodogne]

Dear Nilesh,

> Etienne filed unblock request for orthanc:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989504
> 
> *However*, you will also have to do it for orthanc-webviewer,
> orthanc-wsi, orthanc-dicomweb -- 3 separate unblock requests.
> 
> They are packages without autopkgtests, and need manual unblock by
> the release team. The date for full freeze is 10 July
> (https://lists.debian.org/debian-release/2021/06/msg00168.html) hence
> please file these unblock requests at the earliest, else these
> plugins will not migrate

Thanks for the heads-up!

I have just introduced the 3 unblock requests:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989610
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989611
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989613

Best Regards,
Sébastien-

Re: Static linking without using a Built-Using attribute

[Sébastien Jodogne]

> Thanks Nilesh for the permissions, I begun with upload of
> orthanc 1.9.2+really1.9.1+dfsg-1 source changes.  Sébastien, I
> let you proceed with the plugins, since you seemed willing to do
> it yourself.

Great!

Just an additional question: In your previous message, you mentioned the
need to file a request to manually unblock the migration to bullseye.
Will you take care of introducing this request?

Thanks again, and have a nice day too :-)
Sébastien-

Re: Static linking without using a Built-Using attribute

[Sébastien Jodogne]

Dear Nilesh,

Thank so much for your great explanations! They were really useful for
me to understand what is happening here.


Dear Étienne,

Wow, I am extremely grateful for your resolution... I would never have
managed to get it by myself given my lack of experience.

I'm obviously fine with your changes (to which I had a look), as they
seem to be perfectly in line with Nilesh's explanations.

It would indeed be great if you could do the team upload: This would
prevent any mishandling of the bullseye branch on my side.

Once the team upload is accepted, I will try to fix by myself the three
plugin packages by adding the "Built-Using" attribute in their bullseye
branch, replicating your process on the main "orthanc" source package.


Many thanks again to both of you,
Sébastien-



On 5/06/21 10:38, Étienne Mollier wrote:
> Hi Sébastien,
> 
> Étienne Mollier, on 2021-06-04:
>> Sébastien Jodogne, on 2021-06-04:
>>> In practice, should I first sync my git repository with the tag
>>> "orthanc-1.9.2+dfsg-1", do the modifications and upload to unstable,
>>> then merge back my modifications in the mainline of the git repository,
>>> and finally upload "orthanc-1.9.3+dfsg-2" to experimental?
>>
>> As I understand things, again in the context of a revert from to
>> 1.9.2+dfsg-1 to 1.9.1+dfsg-1, I would probably checkout the
>> 1.9.1+dfsg-1 to get to the state of the package as it was, both
>> regarding the upstream and debian branches, then append in
>> d/changelog the unmodified content of the 1.9.2+dfsg-1 upload
>> and the entry for 1.9.2+really1.9.1+dfsg-1, which should only
>> indicate the revert of the package to the state it was in in
>> version 1.9.1+dfsg-1, and tag debian/1.9.2+really1.9.1+dfsg-1.
>>
>> The resulting debdiff between orthanc_1.9.1+dfsg-1.dsc and
>> orthanc_1.9.2+really1.9.1+dfsg-1.dsc should, ideally, only show
>> the added entries in the changelog.
>>
>> Note I may not have the best git skills in the world, it just
>> sounds like the simplest approach to me.
> 
> I implemented the idea I had in mind in the attached debdiff
> against the source code of the orthanc version in testing.  Note
> that I adjusted a filter on the package version, in order to get
> the right upstream version out of the package version in case a
> +really field is applied, otherwise the package would fail to
> build from source due to attempts to move around libraries with
> an 1.9.2 soversion, instead of 1.9.1.  In doubt I also ran a
> binary debdiff, to make sure there were no other surprises, at
> least in terms of file naming.  The binary debdiff in attachment
> shows no difference other than the bump to the +really version.
> 
> Please have a look and let me know if you are fine with the
> changes.  I'm happy to push the bullseye branch I forked from
> orthanc debian/1.9.1+dfsg-1 in Salsa if you are okay with it; or
> you can just cherry pick the debdiff and make the adjustments I
> might have missed if you prefer.
> 
> Just a VCS note if you go the bullseye branch route: it won't
> need to be merged back to your main trunk, but will remain
> dedicated to the bullseye release life cycle.
> 
> Have a nice day,  :)
> 

Re: Static linking without using a Built-Using attribute

[Sébastien Jodogne]

Dear Nilesh,

Thank you very much for your help!


On 4/06/21 11:45, Nilesh Patra wrote:
> Hi Sébastien
> 
> On Fri, 4 Jun, 2021, 2:15 pm Sébastien Jodogne,
> mailto:s.jodo...@orthanc-labs.com>> wrote:
> 
> 
> Adrian (Bunk) replied that "This is fixable with a +really version."
> [...]
> +really is used when version changes aren't consistent, or you need to
> downgrade.
> 
> In this case, you would want to downgrade orthanc right?

To be fair, I am unsure whether I need to downgrade orthanc to 1.9.2, or
to make an additional operation on 1.9.3.


> So you should use this trick only for orthanc to my understanding.

In the hypothesis that I must downgrade from "orthanc-1.9.3+dfsg-1" to
"orthanc-1.9.2+dfsg-1", should I upload a release with version
"orthanc-1.9.2+really" to unstable?

Or should I name it "orthanc-1.9.2+dfsg-1-really"?

In practice, should I first sync my git repository with the tag
"orthanc-1.9.2+dfsg-1", do the modifications and upload to unstable,
then merge back my modifications in the mainline of the git repository,
and finally upload "orthanc-1.9.3+dfsg-2" to experimental?


> Also note that it is unclear to me what exact package should be put in
> "Built-Using". Is it "src:orthanc", "liborthancframework1", or
> "liborthancframework-dev",
> 
> 
> All libraries that you have statically linked against. See the binary
> packages that are relevant/contain the files that are being used for linking
> 
> with or without version?
> 
> 
> With version, and more specifically with an exactly = relation.
> Please see the Debian Developers reference wherein it's clearly explained.

>From what I see in the Debian Developers reference [1], and from your
explanations, I guess I should use:

Built-Using: liborthancframework-dev (= 1.9.2+really)

Thanks again,
Sébastien-


[1] https://www.debian.org/doc/debian-policy/ch-relationships.html

Static linking without using a Built-Using attribute

[Sébastien Jodogne]

Dear all,

This message is about the three following related bugs in the packages
of the Orthanc family:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989126 (orthanc-wsi)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989127 (orthanc-webviewer)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989128 (orthanc-dicomweb)

All these packages have recently been updated to statically link against
the "liborthancframework1" package, because the ABI of the latter C++
library is not stabilized yet (this library is internal and allows
sharing code between Orthanc plugins). This explains why the
"Built-Using" attribute must be added.

However, I now face a problem: I mistakenly uploaded
"orthanc-1.9.2+dfsg-1" to unstable during the hard freeze period,
whereas it should have been uploaded it to experimental:
https://salsa.debian.org/med-team/orthanc/-/blob/master/debian/changelog

Andreas (Tille) explained that we now "need to link the affected
packages (orthanc-wsi, orthanc-webviewer and orthanc-dicomweb) against
the orthanc-dev in testing since unstable has a newer version."

Adrian (Bunk) replied that "This is fixable with a +really version."

Unfortunately, this is visibly a non-trivial procedure that is out of
the scope of my personal experience. In particular, I don't understand
to what package the "+really" version should apply (to "orthanc", or to
the 3 problematic packages?).

Also note that it is unclear to me what exact package should be put in
"Built-Using". Is it "src:orthanc", "liborthancframework1", or
"liborthancframework-dev", with or without version? I am also unsure
whether a new upload of the "orthanc" package should be done.

Please could someone help solving these issues by providing me with a
step-by-step guide, or by fixing one the three packages so that I can
mimic the resolution on the two others?

Kind Regards,
Sébastien-

PS: Andreas is unavailable for the moment to help and fix these issues.

Re: [Debian-med-packaging] Bug#973612: I'm afrait I did some kind of sabotage by upgrading civetweb ... [karsten.hilb...@gmx.net: Bug#973612: orthanc: libcivetweb version mismatch]

[Sébastien Jodogne]

Hello,

After some investigation, I think that this issue comes from the fact
that the "libcivetweb1" package (as of version 1.13+dfsg-2) doesn't
contain a symbolic link from "libcivetweb.so.1" to "libcivetweb.so.1.13.0".

Because of this missing symbolic link, Orthanc is linked against one
single version of the civetweb shared library (namely,
"libcivetweb.so.1.13.0"), and this library might be unavailable if an
earlier version of "libcivetweb1" was installed beforehand (in Karsten's
case, "libcivetweb.so.1.11.0"), even if the two versions are binary
compatible.

I feel like this corresponds to the warning
"package-name-doesnt-match-sonames" that was reported by Lintian.

In order to solve this issue, I've just submitted a new release of
civetweb (1.13+dfsg-3) that creates the missing symbolic link
"libcivetweb.so.1" by appropriately setting the SOVERSION in CMake,
which required a patch [1].

When Orthanc will be compiled against this new version of civetweb, it
should hopefully be linked against "libcivetweb.so.1" instead of
"libcivetweb.so.1.13.0", making it compatible with a whole range of
versions of civetweb, and it should thus be possible to upgrade civetweb
without breaking Orthanc. If this is indeed the case, I'll soon be able
to make a new release of Orthanc that fixes this issue.

These thoughts might seem trivial to many of you, but I wanted to share
them if someone else meets a similar problem in another context.

Best Regards,
Sébastien-

[1]
https://salsa.debian.org/med-team/civetweb/-/commit/ccb62139b6139ea6efc2432c12018de6e3c16003


On 3/11/20 14:11, Andreas Tille wrote:
> [including the list again]
> Hi Sébastien,
> 
> On Mon, Nov 02, 2020 at 04:39:31PM +0100, Sébastien Jodogne wrote:
>> To be fair, I am unsure to understand the issue and how to fix it...
>>
>> Should I simply modify the "Build-Depends" of the orthanc package to the
>> fix the version of civetweb to 1.13 (i.e. "libcivetweb-dev (= 1.13)")? Or
>> set "Depends" to "libcivetweb1 = 1.13"?
> 
> I do not think so.  The packaging process will usually set versioned
> depends correctly.  Moreover at least in theory orthanc should work with
> both libcivetweb1 versions (1.12 and 1.13) since the soversion was not
> bumped.  To verify this I added a symbols file to 1.12 first and after
> checking that there are only some new symbols in 1.13 I considered it
> harmless to upload (which was obviously wrong).
>  
>> This sounds very strange to me: I would have expected that, as the orthanc
>> package was built against civetweb 1.13 (which is implied by the fact that
>> ldd on "/usr/sbin/Orthanc" indicates "libcivetweb.so.1.13.0"), its
>> "Depends" should have automatically been set to "libcivetweb1 >= 1.13"
>> (whereas ">= 1.12" is found in the .deb package).
> 
> I confirm that the build really injects libcivetweb1 (>= 1.12).  I need
> to admit that I do not know those internals but I would assume that as
> long as the soversion is unchanged the smallest possible version number
> is used here.  But I'm unsure.  I think if for whatever reason >= 1.13
> is needed than this has to be specified explicitly.  But please note
> that I never faced this before and clarifying this on debian-mentors
> might be advisable.
> 
>> Please could you explain it to me?
> 
> Not better than above, sorry. :-(
> 
> Kind regards
> 
>Andreas.
>  
>> On Mon, 2 Nov 2020 at 15:36, Andreas Tille  wrote:
>>
>>> Hi Sébastien,
>>>
>>> hopefully that can easily be fixed - sorry for the inconvenience
>>>
>>>  Andreas.
>>>

Source upload of orthanc-gdcm

[Sébastien Jodogne]

Hello,

The NEW package "orthanc-gdcm" was accepted into unstable two days ago.
However, it looks like I don't have the permission to do a source upload
for this package [1].

What can I do to gain this permission? Thanks in advance!

Kind Regards,
Sébastien-


[1]
https://alioth-lists.debian.net/pipermail/debian-med-packaging/2020-November/085830.html

Fix of orthanc-gdcm

[Sébastien Jodogne]

Dear all,

This is a follow-up to the rejection of the NEW package "orthanc-gdcm"
in July 2020 [1].

As the packages "liborthancframework*" were accepted in unstable
yesterday, I have been able to refactor the "orthanc-gdcm" so that it
doesn't depend on the source code of Orthanc anymore. The resulting
package is now much simpler [2].

Andreas, please would you kindly review the new version of the package,
and possibly upload it again to the NEW queue? As always, many thanks in
advance :-)

Best Regards,
Sébastien-


[1]
https://alioth-lists.debian.net/pipermail/debian-med-packaging/2020-July/082973.html
[2] https://salsa.debian.org/med-team/orthanc-gdcm

Re: Rejection of Orthanc

[Sébastien Jodogne]

Hello again,

>>> May be we can even push orthanc to new *after* civetweb and I explicitly
>>> hint ftpmaster about the needed sequence to accept both.
>>
>> Yes, if you wish, I can prepare a "orthanc-1.7.3+dfsg-3" that links
>> against the "civetweb" package, and that simultaneously re-enables the
>> "Orthanc framework" shared library.
>>
>> Can I do this work now and let you know once it's ready?
> 
> Yes, feel free to do so and ping me afterwards.

Here it is, with tag "debian/1.7.3+dfsg-3":
https://salsa.debian.org/med-team/orthanc/-/tags/debian%2F1.7.3+dfsg-3

Have a nice evening,
Sébastien-

Re: Rejection of Orthanc

[Sébastien Jodogne]

Hello,

> Argh, I forgot git pull before running dput - hope my dcut will be right
> in time to fix this without ftpmaster interaction.  Thanks a lot for
> watching me in this respect in any case!

Great: I see that civetweb_1.12+dfsg-1 has just been put into the NEW queue.

>> As soon as the "civetweb" package is accepted as NEW, I'll update the
>> "orthanc" to take advantage of it. Then, we'll be able to re-submit the
>> adaptations to create the "Orthanc framework" shared library, which will
>> ultimately allow us to re-submit the rejected "orthanc-gdcm" package
>> (Orthanc cannot take advantage of GDCM as long as the latter is not
>> available). I hope this process won't take too long.
> 
> May be we can even push orthanc to new *after* civetweb and I explicitly
> hint ftpmaster about the needed sequence to accept both.

Yes, if you wish, I can prepare a "orthanc-1.7.3+dfsg-3" that links
against the "civetweb" package, and that simultaneously re-enables the
"Orthanc framework" shared library.

Can I do this work now and let you know once it's ready?

> Happy about this nice cooperation

I'm happy too,
Sébastien-

Re: Rejection of Orthanc

[Sébastien Jodogne]

Hello,

>> One could also consider building the C++ library by setting
>> "-CIVETWEB_ENABLE_CXX=ON", which produces the "libcivetweb-cpp.(a|so)"
>> C++ library together with the "libcivetweb.(a|so)" C library. Note
>> however that the C++ library is not used by Orthanc.
>> [...]
> 
> I think we should do the bare minimum for this package to fulfill your
> requirement for orthanc.  In case someone might ask for further features
> later we can add those (and at least will learn that our packaging
> effort had some additional use ;-) ).

Fine, I also like the lean way of things ;-)

> Please check my packaging *thoroughly*.  I'm not sure whether we should
> rename the lib package according to
> 
> libcivetweb1: package-name-doesnt-match-sonames libcivetweb1.11.0
> 
> No idea how many parallel installations of this lib with different
> versions is to be expected.

That's indeed most probably an overkill, at least as long as Orthanc is
the only user of civetweb in Debian.

I have run FOSSology, which allowed me to identify some missing
information in "d/copyright". I took the liberty of fixing this with the
following commit:
https://salsa.debian.org/med-team/civetweb/-/commit/3812231f6d3fa59827fa3c96c0409be4525bb8e3

Regarding the size of the source package, the file
"resources/civetweb.psd" is a large image that weights 9MB on its own,
and that is not used by the package. Maybe one could consider removing it?

> Otherwise the package should be OKis and I issued an ITP.  I'll wait
> for your final confirmation before uploading.

I hereby confirm that I'm able to build the "civetweb" package from
source, and that I'm able to build the "orthanc" package by applying the
attached patch. I feel like the package is ready for upload.

As soon as the "civetweb" package is accepted as NEW, I'll update the
"orthanc" to take advantage of it. Then, we'll be able to re-submit the
adaptations to create the "Orthanc framework" shared library, which will
ultimately allow us to re-submit the rejected "orthanc-gdcm" package
(Orthanc cannot take advantage of GDCM as long as the latter is not
available). I hope this process won't take too long.

> Exactly this was my intention! ;-)  Nice to hear that it seems to
> work.

:-)

Sébastien-

diff -urEb orthanc_1.7.3+dfsg-2.orig/debian/control orthanc_1.7.3+dfsg-2/debian/control
--- orthanc_1.7.3+dfsg-2.orig/debian/control2020-08-27 12:31:03.0 +0200
+++ orthanc_1.7.3+dfsg-2/debian/control 2020-09-15 12:16:26.643754834 +0200
@@ -9,6 +9,7 @@
doxygen,
libboost-all-dev,
libcharls-dev,
+   libcivetweb-dev,
libcurl4-openssl-dev | libcurl4-dev,
libdcmtk-dev,
libgtest-dev,
diff -urEb orthanc_1.7.3+dfsg-2.orig/debian/rules orthanc_1.7.3+dfsg-2/debian/rules
--- orthanc_1.7.3+dfsg-2.orig/debian/rules  2020-08-27 12:31:03.0 +0200
+++ orthanc_1.7.3+dfsg-2/debian/rules   2020-09-15 12:25:35.155767849 +0200
@@ -23,8 +23,6 @@
-DCMAKE_SKIP_RPATH:BOOL=ON \
-DSTATIC_BUILD:BOOL=OFF \
-DSTANDALONE_BUILD:BOOL=ON \
-   -DENABLE_CIVETWEB:BOOL=ON \
-   -DUSE_SYSTEM_CIVETWEB:BOOL=OFF \
-DUSE_GOOGLE_TEST_DEBIAN_PACKAGE:BOOL=ON \
-DDCMTK_LIBRARIES:STRING=dcmjpls \
-DUNIT_TESTS_WITH_HTTP_CONNEXIONS:BOOL=OFF \
@@ -82,7 +80,7 @@
localedef -f UTF-8 -i en_US $(DESTDIR)/locale/en_US.UTF-8/
 
( cd BuildFramework && LOCPATH=$(DESTDIR)/locale/ LD_LIBRARY_PATH=. ./UnitTests-prefix/src/UnitTests-build/UnitTests )
-   ( cd BuildServer && LOCPATH=$(DESTDIR)/locale/ ./UnitTests )
+   ( cd BuildServer && LOCPATH=$(DESTDIR)/locale/ ./UnitTests --gtest_filter=-Version.CivetwebCompression )
 endif
 
 override_dh_clean:

Re: Rejection of Orthanc

[Sébastien Jodogne]

Hi Andreas,

> I agree but need to work on this package structure.  May be I also
> check hor to provide a .a static lib for the -dev package.

I had a look at the CMake stuff, and it visibly doesn't allow the
simultaneous generation of the .so shared lib together with the .a
static lib.

As a consequence, one has to build twice civetweb, once with the
"-DBUILD_SHARED_LIBS=ON" option (to get the .so), and once without this
option (to get the .a).

One could also consider building the C++ library by setting
"-CIVETWEB_ENABLE_CXX=ON", which produces the "libcivetweb-cpp.(a|so)"
C++ library together with the "libcivetweb.(a|so)" C library. Note
however that the C++ library is not used by Orthanc.

The "include/CivetServer.h" corresponds to the C++ header file, whereas
the "include/civetweb.h" corresponds to the C header (the latter being
the only one used by Orthanc).

If you prefer, I can try and write the "d/rules" given these hints, once
you have imported the Git repository and created the skeleton of the
package.

> Please note: I removed the Git repository since I had to rebuild the
> tarball to get rid of several unneeded code copied of third party
> software.  I simply wanted to save space inside the Git repository.  (I
> also need to get rid of the remaining jquery.js so the current tarball
> is not yet final but I will not recreate the repository again.) 

Actually, the core of civetweb is quite small wrt. to the size of the
tarball: The "src" and "include" directories are the only mandatory
subfolders, as long as the tests and the extensions are not built.

> Thank you for your comments and I hope I can contribute to the
> enhancement of orthanc by packaging this.

I'm extremely grateful for your help, that clearly stimulates me to
continue the Debian maintenance.

Thanks again,
Sébastien-

Re: Rejection of Orthanc

[Sébastien Jodogne]

> It somehow smells like an attempt to access some remote location.  Given
> that you have somehow build this before in a restricted chroot is there
> any trick I can prevent this? 

I confirm that the CMake of civetweb by default requires access to
Internet. After some testing, here is the proper way of invoking CMake
to avoid such access:

$ cd civetweb-1.12
$ mkdir Build
$ cd Build
$ cmake .. -DCMAKE_BUILD_TYPE=None -DCIVETWEB_BUILD_TESTING=OFF
-DBUILD_SHARED_LIBS=ON

I have set the "CMAKE_BUILD_TYPE" is set to "None" for reasons explained
by Mathieu Malaterre in the following Debian issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711515

After building, here is what I would expect as the main content of the
binary packages:

- "civetweb" package (standalone executable, unused by Orthanc) =>
civetweb-1.12/Build/src/civetweb
- "libcivetweb1" => civetweb-1.12/Build/src/libcivetweb.so.1.11.0
- "libcivetweb-dev" => civetweb-1.12/include/civetweb.h

HTH,
Sébastien-

Re: Rejection of Orthanc

[Sébastien Jodogne]

Dear Andreas,

>> Is there anyone willing to provide help?
> 
> I injected basically what our package_template creates to
> 
> https://salsa.debian.org/med-team/civetweb
> 
> It is by no means a functional packaging yet.

Thanks so much for your support and for taking this issue into
consideration.

> What I'm stumbling about is that the tarball you
> included in orthanc is way smaller than what uscan gets:
> 
> $ ls -l debian/ThirdPartyDownloads/
> -rw-r--r-- 1 andreas admin 3035855 28. Mai 16:17 civetweb-1.12-fixed.tar.gz
> 
> $ ls -l civetweb-1.12.tar.gz civetweb_1.12.orig.tar.gz 
> lrwxrwxrwx 1 andreas admin   20 14. Sep 15:56 civetweb_1.12.orig.tar.gz 
> -> civetweb-1.12.tar.gz
> -rw-r--r-- 1 andreas admin 11463079 14. Sep 15:56 civetweb-1.12.tar.gz

The reason of existence for "civetweb-1.12-fixed.tar.gz" is explained in
the following source file of Orthanc:
https://salsa.debian.org/med-team/orthanc/-/blob/a1c4aa701a14668eb0683a94d10a41d4fd8a9efc/OrthancFramework/Resources/CMake/CivetwebConfiguration.cmake#L23

Basically, the original civetweb archive contains filenames with special
characters, which causes problems if compiling on older versions of
Microsoft Windows (this is the case of our continuous integration
server). This is by no way an issue on GNU/Linux systems, and one can
directly use the original archives, as can be found on GitHub:
https://github.com/civetweb/civetweb/releases

I'll be obviously very interested in linking Orthanc with a Debian
package for civetweb. It should be as simple as removing the
"-DUSE_SYSTEM_CIVETWEB:BOOL=OFF" in the d/rules of the orthanc package:
https://salsa.debian.org/med-team/orthanc/-/blob/master/debian/rules

Thanks again,
Sébastien-

Rejection of Orthanc

[Sébastien Jodogne]

Dear all,

I take the liberty of relaying the message below to the main Debian Med
mailing list.

As I can understand, the "orthanc" package was rejected yesterday by the
FTP master because of the presence of the source of 3 third-party
JavaScript components that are not packaged in Debian yet (namely,
Date.js, jQuery and jQuery Mobile), as well as the presence of the
source code of civetweb:
https://salsa.debian.org/med-team/orthanc/-/tree/master/debian/JS
https://salsa.debian.org/med-team/orthanc/-/tree/master/debian/ThirdPartyDownloads

There is no licensing issue here. The JavaScript components have been
present in the source of the "orthanc" package for more than 4 years,
and Orthanc embedded interface only works with jQuery Mobile version
1.1.0 (yes, this will obviously be the subject of criticism, but this
interface was developed in 2011). The dependency on mongoose, then on
civetweb has also been present since the origin of the package back in 2012.

This is a message to beg for help on this topic. I don't have the time
to do more Debian packaging, besides maintaining the packages of the
Orthanc core and official plugins.

Is there anyone willing to provide help? Otherwise, I fear I'll have to
orphan all this 8-year-long work on Orthanc.

I thank you in advance,
Sébastien-



 Forwarded Message 
Subject:Re: [Debian-med-packaging] orthanc_1.7.2+dfsg-2_amd64.changes
REJECTED
Date:   Sun, 13 Sep 2020 19:28:29 +0200
From:   Sébastien Jodogne 
To: Thorsten Alteholz 
CC: Andreas (Debian) , Debian Med Packaging Team




Hello Thorsten,

I'm sorry, but I do not understand this rejection. The only NEW
subpackages are related to the shared library for the Orthanc plugins,
and this rejection blocks any further development of Orthanc in Debian.
This is completely disheartening to me, given the full weeks I've been
spending on Debian packaging.

Please could you someone help and provide assistance? I am not able to
package yet new packages, as I am also the upstream developer of
Orthanc, that is by itself a very large ecosystem.

I do my best to try and provide useful packages related to free software
for healthcare in these COVID times (Orthanc is notably used to handle
CT scans of the lungs), but all these rejections since May seem to
indicate that I'm definitely too stupid to be part of the Debian community. 

Thanks in advance,
Sébastien-


Le dim. 13 sept. 2020 à 19:00, Thorsten Alteholz
mailto:ftpmas...@ftp-master.debian.org>> a écrit :


Hi Sebastien,

please don't hide software in debian/* but create separate source
packages instead.

Thanks!
 Thorsten




===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.

___
Debian-med-packaging mailing list
debian-med-packag...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

Re: Orthanc and all its plugins are getting removed from testing

[Sébastien Jodogne]

As suggested by Andreas, I've been in touch with the FTP team.

Following this discussion, I've uploaded orthanc-1.7.2+dfsg-3 to 
unstable, that doesn't contain the NEW changes.


For reference, here are the two changesets to revert once 
"liborthancframework-dev" and "liborthancframework1" subpackages get 
accepted:


https://salsa.debian.org/med-team/orthanc/-/commit/014c050762fa3804448142968ce63325745d9035
https://salsa.debian.org/med-team/orthanc/-/commit/9a5b353bbd085b5ae2e376d543a11912b55c5d6e

Sébastien-




Because of the bug #966655 [1], and because of the fact that
orthanc-1.7.2+dfsg-2 is pending in the NEW queue [2], I cannot commit
the fix regarding the missing build dependency on tzdata until the NEW
packages get accepted.

But, as #966655 is tagged as serious, the entire Orthanc ecosystem was
removed from Debian testing during this week-end.

Is there anything I can do to prevent this?

Many thanks in advance for your help,
Sébastien-


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966655
[2]
https://alioth-lists.debian.net/pipermail/debian-med-packaging/2020-July/082973.html

Orthanc and all its plugins are getting removed from testing

[Sébastien Jodogne]

Dear all,

Because of the bug #966655 [1], and because of the fact that
orthanc-1.7.2+dfsg-2 is pending in the NEW queue [2], I cannot commit
the fix regarding the missing build dependency on tzdata until the NEW
packages get accepted.

But, as #966655 is tagged as serious, the entire Orthanc ecosystem was
removed from Debian testing during this week-end.

Is there anything I can do to prevent this?

Many thanks in advance for your help,
Sébastien-


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966655
[2]
https://alioth-lists.debian.net/pipermail/debian-med-packaging/2020-July/082973.html

Re: New package - orthanc-gdcm

[Sébastien Jodogne]

Hi Andreas,

>> If this helps, I could consider decompressing the archive and keeping
>> only the required source files. Do you think this possible solution
>> could mitigate the issue?
> 
> Hmmm, I once had the idea that some "Build-Depends: source-package"
> would be somehow handy - but this does not exist unfortunately.  For my
> gut feeling if you can cope with only a few source packages this could
> be possibly more acceptable for ftpmaster.  However, I hope you might
> be able to follow the library idea in the (far) future.

Indeed, the "Build-Depends: source-package" would be really great! Also,
I swear that I am considering the library idea for the Orthanc framework.

As discussed, I have updated the package by extracting the sources of
the Orthanc framework into a dedicated folder:
https://salsa.debian.org/med-team/orthanc-gdcm/-/tree/master/debian/orthanc-framework

HTH,
Sébastien-

Re: New package - orthanc-gdcm

[Sébastien Jodogne]

Hi Andreas,

> I've done
> 
> routine-update -f
> 
> to bring some packaging stuff up to date (please git pull). 

Thanks for your quick feedback!

> What
> prevented me from uploading is debian/ThirdPartyDownloads.  Do you
> really need to provide an orthanc code archive here?  Wouldn't it be
> more straightforward to create a library from orthanc and link against
> this?  I bet ftpmaster would stumble upon this.

This "debian/ThirdPartyDownloads" stuff is for sharing code between the
official Orthanc plugins. Indeed, creating a separate library would be
ideal, but this would require a huge amount of upstream work (which I
can't afford as I must develop new features), and the resulting library
wouldn't be useful out of the official Orthanc plugins.

If this helps, I could consider decompressing the archive and keeping
only the required source files. Do you think this possible solution
could mitigate the issue?

Best,
Sébastien-

New package - orthanc-gdcm

[Sébastien Jodogne]

Hello,

I have prepared a new package for Debian that is called "orthanc-gdcm",
and that is related to both Orthanc and GDCM.

More precisely, this is a plugin to use the GDCM library in order to
transcode and decode images, in place of the default DCMTK-based
transcoder/decoder that is built in Orthanc [1].

An initial version of the package has been pushed to Salsa [2], and is
associated with ITP #961716 [3].

Please could someone consider this package for review, and possibly for
upload to the NEW queue?

Thanks in advance!
Sébastien-


[1] https://book.orthanc-server.com/plugins/gdcm.html
[2] https://salsa.debian.org/med-team/orthanc-gdcm
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961716

Re: New target: Re-introduce slicer (Was: Please help to specify COVID-19 packages)

[Sébastien Jodogne]

Hello,

On 24/03/20 09:31, Andreas Tille wrote:

Regarding COVID-19, I'm currently working on enabling Python scripting in
Orthanc to automate routing of medical images in hospitals, and on a new
generation of 3D viewers (MPR) that can display CT-scans directly in the Web
browsers through WebAssembly. (BTW, an updated version of the "emscripten"
package would be needed to have an official Debian package of such a Web
viewer.)


Did you files a bug report against emscripten?  We might consider to use
some "COVID-19 relevant" text snippet in the title of the bug.


Regarding the emscripten package, there is already a large number of 
pending bugs:

https://tracker.debian.org/pkg/emscripten

I'm unsure whether adding another one would help here. As the package 
has not been updated for more than 5 years, I fear this package should 
actually be considered as orphaned.


Sébastien-

Initial upload of new package "orthanc-python"

[Sébastien Jodogne]

Dear all,

I have just packaged a new plugin for Orthanc that can be used to write 
Orthanc plugins using the Python programming language instead of the 
more complex C/C++ programming languages [1].


An initial version of the package is now available on Salsa [2].

Please could some Debian Developer review this package, then upload it 
to the NEW queue if it is OK? Many thanks in advance!


Kind Regards,
Sébastien-


[1] https://book.orthanc-server.com/plugins/python.html
[2] https://salsa.debian.org/med-team/orthanc-python

Re: Please help to specify COVID-19 packages [nore...@release.debian.org: macs REMOVED from testing]

[Sébastien Jodogne]

Dear Andreas,

All the packages related to X-ray chest and CT-scan radiology in 
clinical setups can be considered as relevant to COVID-19 [1]. DICOM 
viewers (2D + MPR) and DICOM servers that work out-of-the-box are 
probably useful.


Among others, this includes the packages from the "orthanc" family 
(disclaimer: I'm the author of Orthanc).


Regarding COVID-19, I'm currently working on enabling Python scripting 
in Orthanc to automate routing of medical images in hospitals, and on a 
new generation of 3D viewers (MPR) that can display CT-scans directly in 
the Web browsers through WebAssembly. (BTW, an updated version of the 
"emscripten" package would be needed to have an official Debian package 
of such a Web viewer.)


As far as I'm concerned, as all my free time is dedicated to this work, 
it is not possible for me to help on Debian packaging besides the 
"orthanc*" packages I maintain.


Other related packages in Debian Med [2] notably include aeskulap, 
conquest, dcmtk, ginkgocadx, imagej, gdcm, and slicer. Also, note that 
GNU Health now features an Orthanc integration [3].


This list is by no way exhaustive!

Kind Regards,
Sébastien-


[1] 
https://www.acr.org/Advocacy-and-Economics/ACR-Position-Statements/Recommendations-for-Chest-Radiography-and-CT-for-Suspected-COVID19-Infection

[2] https://blends.debian.org/med/tasks/imaging
[3] https://pypi.org/project/gnuhealth-orthanc/



On 24/03/20 07:06, Andreas Tille wrote:

Hi folks,

I'm **REALLY** waiting for input which of our packages are
COVID-19 relevant.  Where should we put our focus on?
Are bugs in macs more relevant than other packages and who
is willing to fix those bugs?

Thanks a lot for any input

   Andreas.

Talk about Debian Med at GNUHealthCon / OrthanCon

[Sébastien Jodogne]

Dear community,

A few time ago, I posted an announcement about the organization of a 
conference about free software for health informatics and medical 
imaging [1]. This conference will take place in Liège (Belgium), on 
December 13-15, 2019 [2].


I feel having a talk about the Debian Med project during the plenary 
sessions of that event should be really nice!


Would someone be interested in giving such a talk? Andreas is 
unfortunately unavailable by that time.


Best Regards,
Sébastien-

PS: Obviously, talks from other projects are welcome as well! [3]


[1] https://lists.debian.org/debian-med/2019/05/msg00030.html
[2] http://conference.orthanc-server.com
[3] https://www.orthanc-server.com/static.php?page=conference#call

Joint conferences - IWEEE 2019, GNUHealthCon 2019 and OrthancCon 2019

[Sébastien Jodogne]

Dear all,

I take the liberty of informing you that we're organizing a conference
about free software for healthcare and social medicine in Liège
(Belgium), on December 13-15, 2019.

This event is a joint organization between IWEEE/GNUHealthCon 2019, the
yearly meetings of the GNU Health community, and OrthancCon 2019, the
first edition of the conference about Orthanc and free software for
medical imaging. All the practical information can be found on our two
associated Web sites:

- http://www.gnuhealthcon.org/2019-liege/
- http://conference.orthanc-server.com/

The calls for presentations are now available for both conferences. It
would evidently be great to benefit from talks about projects
affiliated with Debian Med!

Kind Regards,
Sébastien-

Joint conferences - IWEEE 2019, GNUHealthCon 2019 and OrthancCon 2019

[Sébastien Jodogne]

Dear all,

I take the liberty of informing you that we're organizing a conference
about free software for healthcare and social medicine in Liège
(Belgium), on December 13-15, 2019.

This event is a joint organization between IWEEE/GNUHealthCon 2019, the
yearly meetings of the GNU Health community, and OrthancCon 2019, the
first edition of the conference about Orthanc and free software for
medical imaging. All the practical information can be found on our two
associated Web sites:

- http://www.gnuhealthcon.org/2019-liege/
- http://conference.orthanc-server.com/

The calls for presentations are now available for both conferences. It
would evidently be great to benefit from talks about projects
affiliated with Debian Med!

Kind Regards,
Sébastien-

Fwd: orthanc-mysql_1.1-1_amd64.changes REJECTED

[Sébastien Jodogne]

Hello,

I have received the following message after trying and uploading a new 
release of the "orthanc-mysql" package.


Please could someone allow me to do the upload by myself? Thanks in advance!

Regards,
Sébastien-




 Forwarded Message 
Subject: orthanc-mysql_1.1-1_amd64.changes REJECTED
Date: Tue, 13 Nov 2018 15:43:46 +
From: Debian FTP Masters 
To: Debian Med Packaging Team 
, Sebastien Jodogne 





ACL dm: not allowed to upload source package 'orthanc-mysql'



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.

Re: Bootstrapping a new project on Salsa

[Sébastien Jodogne]

Hi,


Would it be possible for you to sponsor this new package?


Uploaded.  BTW, **I** **personally** do not require you to do the extra
step on mentors.d.n.  I do not visit this site but just sponsor from our
Git repository.


Perfect! Duly noted.

Thanks again,
Sébastien-

Re: Bootstrapping a new project on Salsa

[Sébastien Jodogne]

Hi Andreas,


Please could someone indicate me how I can bootstrap a new GitHub repository
dedicated to this new "orthanc-mysql" package? TIA!


You have now permissions to do so yourself.  I repeat my recommendation
to use inject-into-salsa-git as described here:

 https://lists.debian.org/debian-med/2018/07/msg00077.html


I have successfully committed the package source to Salsa, and the 
binary package is now pending in the NEW queue:


 https://mentors.debian.net/package/orthanc-mysql

Would it be possible for you to sponsor this new package?

Additionally, I've accidentally created a test repository on Salsa in 
the process, but I'm not allowed to delete it by myself... sorry for 
this mistake! Please could you delete the following repository (that is 
empty)?


 https://salsa.debian.org/med-team/orthanc-mysql.bad

Once again, many thank for your hard work and for your support!

Sébastien-

Bootstrapping a new project on Salsa

[Sébastien Jodogne]

Hello,

I am in the process of packaging a new set of plugins in order to bring 
MySQL/MariaDB support to Orthanc [1]. An ITP has just been filled [2].


Please could someone indicate me how I can bootstrap a new GitHub 
repository dedicated to this new "orthanc-mysql" package? TIA!


Kind Regards,
Sébastien-


[1] https://www.orthanc-server.com/browse.php?path=/plugin-mysql
[2] https://lists.debian.org/debian-devel/2018/07/msg00254.html

Re: NDEBUG and CMake

[Sébastien Jodogne]

Dear Gert,

On 26/04/18 09:47, Gert Wollny wrote:


Am Mittwoch, den 25.04.2018, 12:32 +0200 schrieb Sébastien Jodogne:


cmake -DCMAKE_C_FLAGS=-DNDEBUG -DCMAKE_CXX_FLAGS=-DNDEBUG [...]

Please someone could validate this approach? TIA!


Add this at the top of d/rules:

export DEB_CFLAGS_MAINT_APPEND=-DNDEBUG
export DEB_CXXFLAGS_MAINT_APPEND=-DNDEBUG


Great! This is exactly what I was looking for.

I've just issued a new version of the package with the following changeset:
https://salsa.debian.org/med-team/orthanc/commit/00c5667406469adf499d66d93c2a0011dac4b778

Many thanks,
Sébastien-

Re: NDEBUG and CMake

[Sébastien Jodogne]

Hello,

Have you tried RelWithDebInfo as the build type? 
(https://cmake.org/Wiki/CMake_Useful_Variables)


This should set NDEBUG but still use -g to get debug symbols.


Thanks for the reply. However, previous discussions on Debian clearly 
state that CMAKE_BUILD_TYPE must be set to None, not to "RelWithDebInfo" 
[1].


Sébastien-


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711515#51

NDEBUG and CMake

[Sébastien Jodogne]

Dear all,

The Debian packages for Orthanc and its associated plugins pay attention 
to the fact of *not* setting "-DCMAKE_BUILD_TYPE=Release", as requested 
by the Debian policy [1].


However, the source code of the upstream Orthanc project makes many 
calls to the "assert()" function of the standard library [2], in order 
to help with the early tracking of bugs. All those assertions are 
extremely time-consuming, and should only be enabled in debug builds.


The assertions can be disabled by defining the macro "NDEBUG" while 
compiling the software. Invoking CMake with "-DCMAKE_BUILD_TYPE=Release" 
would make "NDEBUG" defined, at least for gcc and clang [3]. However, 
because packages of the Orthanc family are built using 
"-DCMAKE_BUILD_TYPE=None", the Orthanc log warns about bad performance:



$ sudo apt-get install orthanc
$ head /var/log/orthanc/Orthanc.log
W0424 13:01:40.158634 main.cpp:1298] Orthanc version: 1.3.2
W0424 13:01:40.158696 main.cpp:1146] Performance warning: Non-release 
build, runtime debug assertions are turned on



I have not been able to find a definite answer about how "NDEBUG" should 
be properly handled. I am considering to add the following arguments 
wile invoking CMake in debian/rules in order to have "NDEBUG" manually 
defined:


cmake -DCMAKE_C_FLAGS=-DNDEBUG -DCMAKE_CXX_FLAGS=-DNDEBUG [...]

Please someone could validate this approach? TIA!

Regards,
Sébastien-

PS: I mistakenly sent this message yesterday to 
"debian-devel-annou...@lists.debian.org". Please excuse my error.



[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711515#51
[2] http://www.cplusplus.com/reference/cassert/assert/
[3] https://stackoverflow.com/a/34314956/881731

Re: FOSDEM devroom

[Sébastien Jodogne]

Dear Andreas and Cedric,

First of all, thanks to both of you for your interest and for your answers!

Unfortunately, only two persons showed an interest in showcasing some
free software in such a FOSDEM devroom. Furthermore, as I sadly don't
work for an University, my full-time daily job doesn't allow me to
organize or host a Debian sprint.

I will probably come back to the mailing list in about one year with the
same proposition to organize "FOSS for Healthcare devroom". Maybe there
will be more interest on that time.

In the meantime, I prefer to focus on the development of Orthanc...
spending my sparse time organizing a FOSDEM event would indeed result in
the starvation of Orthanc for a few months.

Warm Regards,
Sébastien-



On 26/08/17 11:43, Cédric Lood wrote:
> Hi there,
> 
 This devroom could be entitled "FOSS for Healthcare", and could be a
 sequence of talks presenting various FOSS projects, pretty like the
 "FOSS for Scientists devroom" of the 2013 edition [2].

 In order to avoid doing any unnecessary work, it would be nice to know
 upfront whether some DebianMed contributors would be interested to give
 a talk in such a devroom. Please could you express your interest?
> 
> I just joined the debian-med project so wouldn't give a talk.
> 
>>> Thanks for the FOSDEM wakeup call.  I admit I did not joined FOSDEM for
>>> years since it either conflicted by date with the Debian Med sprint or
>>> I did not wanted to travel on subsequent weekends.  While I like your
>>> idea my constraint would remain valid except if we would organise our
>>> yearly Debian Med sprint either in Brussels or somewhere closeby (two
>>> days before or after FOSDEM and use the Healthcare dedicated room also
>>> for common hacking to continue our sprint).
> 
>> Brussel (or nearby) would be a good idea if indeed right before/after Fosdem 
>> (would love to go to Fosdem too). But if I am correct FOSDEM is on 
>> week-ends, so this means our sprint would occur during the week.
>> This is not an issue for me as my university would consider it as part of my 
>> job, but this may be an issue for others, no?
> 
> Same here. 
> 
> I would love to participate to a sprint - I work at the uni of Leuven (KUL), 
> which is not far from Brussels, and could book a room there for the team. 
> 
>>> Who is considering this a good idea and who of those who think it is a
>>> good idea would take over organising the sprint?  Sébastien, as far as I
>>> remember you live a one hour train ride from Brussels so if there is a
>>> cheaper place close to you this might work somehow.  I would be happy if
>>> you would become involved since we could strengthen the medical imaging
>>> branch and may be if we could attract the interest of Gnumed /
>>> Freemedforms developers we couls also attract the practice management
>>> interested people.
>>>
>>> On the other hand there was some idea to do the sprint in St. Petersburg
>>> and as always who raises the hand first to volunteer for organising the
>>> sprint will win.
> 
> Best,
> Cedric

FOSDEM devroom

[Sébastien Jodogne]

Dear all,

The next edition of FOSDEM will take place in Brussels, on February 3rd
and 4th, 2018 [1].

The call for participation is not available yet, but wouldn't it be a
good idea to propose to organize a devroom dedicated to free software in
medicine and healthcare?

This devroom could be entitled "FOSS for Healthcare", and could be a
sequence of talks presenting various FOSS projects, pretty like the
"FOSS for Scientists devroom" of the 2013 edition [2].

In order to avoid doing any unnecessary work, it would be nice to know
upfront whether some DebianMed contributors would be interested to give
a talk in such a devroom. Please could you express your interest?

Regards,
Sébastien-


[1] https://fosdem.org/2018/
[2] http://slayoo.github.io/fosdem2013/


-- 
Sébastien Jodogne
Mail: s.jodo...@gmail.com
Web: http://www.sjodogne.be/
Twitter: https://twitter.com/sjodogne

Re: Cannot upload "orthanc"

[Sébastien Jodogne]

> Permissions granted for orthanc orthanc-dicomweb orthanc-imagej
> orthanc-postgresql orthanc-webviewer orthanc-wsi - just let me
> know if you intend to upload other packages.  Its perfectly fine
> to do so for fixing bugs or even taking over the maintenance.
> 
> Happy to see you gaining more freedom to easily contribute

Fine! Thanks to your help, I was just able to do my first standalone
upload to Debian [1] :)

Sébastien-

[1] https://tracker.debian.org/news/850868

Re: Cannot upload "orthanc"

[Sébastien Jodogne]

Hi,

>> Now that I'm qualified as a new DM [1]
> 
> Ahhh, congratulations!

:)


> DMs need to be explicitly granted permissions per package.  Simply send
> me your fingerprint and I'll grant you permissions for uploading all
> orthan* packages.

Great! Here is my fingerprint:

93BE 9F19 7ED5 D0C3 0E59 3D8B A776 582B 312A C35D

It is available on my DM application:
https://nm.debian.org/process/167/keycheck

Thanks,
Sébastien-

Re: Fixes in orthanc-dicomweb and orthanc-webviewer

[Sébastien Jodogne]

Hi Andreas,


Would it be possible for you to sponsor the upload?


Done.


Thanks!


BTW, I'd recommend considering becoming a Debian Maintainer to
enable you uploading yourself. :-)


Yes, I'm still looking for some Debian developer who could sign my key 
after meeting me IRL somewhere in Wallonia. I was unfortunately sick on 
last FOSDEM...


Regards,
Sébastien-

Fixes in orthanc-dicomweb and orthanc-webviewer

[Sébastien Jodogne]

Dear Andreas,

Subsequently to two bug reports introduced by Tiago [1,2], I've just 
updated the "orthanc-dicomweb" [3] and "orthanc-dicomweb" [4] packages.


Would it be possible for you to sponsor the upload?


Dear Tiago,

Thank you much for the fixes!


Regards,
Sébastien-



[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857355
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857424
[3] 
https://anonscm.debian.org/viewvc/debian-med?view=revision=date=23711

[4] https://anonscm.debian.org/cgit/debian-med/orthanc-dicomweb.git/

Re: Orthanc for digital pathology

[Sébastien Jodogne]

Thanks for the so fast upload, Andreas! :)


Could you please suggest task(s) inside the Debian Med scope[1]
where the package fits into?


HIS
IMAGING
LAB
ONCO
PRACTICE

Karsten


I agree with Karsten's selection.

Sébastien-

Re: Orthanc for digital pathology

[Sébastien Jodogne]

Hello Andreas,

Thanks to Thorsten, the "orthanc-wsi" package finally made its way to 
the Debian repositories this morning.


I have just updated the package to the latest upstream release (0.4):
https://anonscm.debian.org/cgit/debian-med/orthanc-wsi.git/

Please would kindly upload the changes? Many thanks in advance!

Warm Regards,
Sébastien-


On 29/12/16 12:54, Andreas Tille wrote:

Hi Sébastien,

On Thu, Dec 29, 2016 at 10:53:41AM +0100, Sébastien Jodogne wrote:

As this package is the first free and open-source, reference implementation
of DICOM for microscopic whole-slide imaging (digital pathology), I think
providing it through Debian could expand the field of scope of the Debian
Med community.


I'm afraid that's a couple of days to late since packages need 10 days
of transition through unstable until reaching testing.  While I guess
this mail is about 2 weeks to late (since ftpmasters can be convinced by
good reasons like you gave above to set priorities) I think there is no
real harm done if we publish this package in Stretch backports.

Re: Orthanc for digital pathology

[Sébastien Jodogne]

Dear all,

The new "orthanc-wsi" package was submitted more than two months ago, 
but is still pending in the NEW queue:

https://ftp-master.debian.org/new.html

As this package is the first free and open-source, reference 
implementation of DICOM for microscopic whole-slide imaging (digital 
pathology), I think providing it through Debian could expand the field 
of scope of the Debian Med community.


As a consequence, I feel it would be important to make sure it gets 
accepted into unstable before the Debian Stretch soft freeze, which will 
occur in the following next days. Is there anything I can do to speedup 
the review process?


Best Regards,
Sébastien-


On 10/31/2016 11:13 AM, Andreas Tille wrote:

Hi Sebastien,

thanks for your preparation.  I've uploaded after moving packaging to
Git since the original tarball was changed.

Kind regards

   Andreas.

On Fri, Oct 28, 2016 at 03:44:45PM +0200, Sebastien Jodogne wrote:

Dear all,

Last Saturday, the Orthanc project released initial support of DICOM for
whole-slide microscopic imaging (digital pathology) [1]. This implementation
tries and follows Supplement 145 [2].

The implementation notably provides a command-line tool to convert
whole-slide images to DICOM, possibly using OpenSlide to decode proprietary
file formats. It also provides a Web viewer of such possibly multi-gigapixel
DICOM images, taking advantage of OpenLayers.

I have just packaged this framework for Debian Sid. The package is already
uploaded to the Subversion repository of Debian Med [3]. I think it is
reasonably lintian-proof.

Andreas, would it be possible for you to give a look at the package, and
possibly upload it to the NEW queue if it looks OK to you? I thank you much
in advance!

Cheers,
Sébastien-


PS: It would perhaps be a good idea to also migrate the package to git, as
there are some DFSG modifications wrt. the upstream tarball.



[1] http://www.orthanc-server.com/static.php?page=blog#wsi
[2] ftp://medical.nema.org/medical/dicom/final/sup145_ft.pdf
[3] 
https://anonscm.debian.org/viewvc/debian-med/trunk/packages/orthanc-wsi/trunk/







--
Sébastien Jodogne, PhD.
Medical Imaging Engineer
Department of Medical Physics

BAT. T1-3 RADIOTHERAPIE
C.H.U. - SART TILMAN - B35
4000 Liège
BELGIUM

Mail: s.jodo...@gmail.com
Web: http://www.montefiore.ulg.ac.be/~jodogne/

Re: Orthanc 1.2.0

[Sébastien Jodogne]

Hi Andreas,

This issue is very low priority wrt. my TODO list for the upstream project.

Anyone is obviously welcome to help me and contribute by packaging this
script into the orthanc Debian package.

Regards,
Sébastien-


Le 14 déc. 2016 06:42, "Andreas Tille" <andr...@fam-tille.de> a écrit :

Hi Sébastien,

On Tue, Dec 13, 2016 at 09:21:01PM +0100, Sébastien Jodogne wrote:
> I have just packaged the newest upstream version of Orthanc (1.2.0):
> http://anonscm.debian.org/cgit/debian-med/orthanc.git/
>
> Andreas, please could you sponsor the upload? Thanks in advance!

Do you plan to provide any upgrade script as it was asked for in

   https://bugs.debian.org/829380

Kind regards

 Andreas.

--
http://fam-tille.de

Orthanc 1.2.0

[Sébastien Jodogne]

Dear all,

I have just packaged the newest upstream version of Orthanc (1.2.0):
http://anonscm.debian.org/cgit/debian-med/orthanc.git/

Andreas, please could you sponsor the upload? Thanks in advance!

Regards,
Sébastien-



--
Sébastien Jodogne
Mail: s.jodo...@gmail.com
Web: http://www.sjodogne.be/
Twitter: https://twitter.com/sjodogne

Re: Bug#844835: orthanc: FTBFS: build-dependency not installable: libssl-dev

[Sébastien Jodogne]

Dear Gert,


orthnac build depends on libdcmtk-dev, and this pulls in libssl1.0-dev
(since dcmtk (a) does not yet support openssl-1.1 and (b) it is used by
programs that require QT which conflicts with openssl-1.1).

libssl1.0-dev conflicts with libssl-dev, and hence the build failure.

The solution is to remove libssl-dev from the build dependencies, since
libdcmtk-dev already takes care of pulling the right version in.


Many thanks for this helpful explanation! I have just pushed your fix, 
together with two other patches [1]. Everything now looks fine in pbuilder.


Andreas, please would kindly sponsor the upload? Once again, thanks to 
both of you for your help!


Regards,
Sébastien-


[1] https://anonscm.debian.org/cgit/debian-med/orthanc.git/log/

Re: Bug#844835: orthanc: FTBFS: build-dependency not installable: libssl-dev

[Sébastien Jodogne]

UPDATE - The following patch makes pbuilder happy again:

>>>>>
diff --git a/debian/control b/debian/control
index 3741d90..302af99 100644
--- a/debian/control
+++ b/debian/control
@@ -19,7 +19,7 @@ Build-Depends: cmake,
libpng-dev,
libpugixml-dev,
libsqlite3-dev,
-   libssl-dev,
+   libssl1.0-dev | libssl-dev,
libwrap0-dev,
unzip,
uuid-dev,
<<<<<

To be fair, I don't understand why this patch works (shouldn't "libssl-dev"
abstract versioning?), and whether this is the correct solution to the bug
report. Please could someone review the patch?

BTW, the same problem will likely also affect the "orthanc-wsi" package
that has been pending in the NEW queue for about 3 weeks:
https://ftp-master.debian.org/new/orthanc-wsi_0.1+dfsg-1.html

Sébastien-



On Sat, Nov 19, 2016 at 10:30 AM, Sébastien Jodogne <s.jodo...@gmail.com>
wrote:

> Dear all,
>
> I have a problem understanding what is going wrong in the attached bug
> report.
>
> If I open the "debian/control" file of the "orthanc" package, I indeed see
> that the package Build-Depends on "libssl-dev":
> https://anonscm.debian.org/cgit/debian-med/orthanc.git/tree/debian/control
>
> However, if I run the following session of commands, I see that
> "libssl-dev" is still available in unstable:
>
> >>>>>
> jodogne@debian-unstable:~$ sudo apt-get update
> Hit:1 http://ftp.belnet.be/debian unstable InRelease
> Reading package lists... Done
> jodogne@debian-unstable:~$ sudo apt-get dist-upgrade
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Calculating upgrade... Done
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> jodogne@debian-unstable:~$ sudo apt-get upgrade
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Calculating upgrade... Done
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> jodogne@debian-unstable:~$ apt-cache search libssl-dev
> libssl-dev - Secure Sockets Layer toolkit - development files
> <<<<<
>
> As a consequence, I don't understand why the rebuild failed. Is it a
> transient issue? Please could someone kindly give me an explanation? Thanks
> in advance!
>
> Regards,
> Sébastien-
>
>
>
> -- Forwarded message --
> From: Lucas Nussbaum <lu...@debian.org>
> Date: Sat, Nov 19, 2016 at 7:26 AM
> Subject: Bug#844835: orthanc: FTBFS: build-dependency not installable:
> libssl-dev
> To: sub...@bugs.debian.org
>
>
> Source: orthanc
> Version: 1.1.0+dfsg-2
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20161118 qa-ftbfs
> Justification: FTBFS on amd64
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
> Relevant part (hopefully):
> > +---
> ---+
> > | Install package build dependencies
>|
> > +---
> ---+
> >
> >
> > Setup apt archive
> > -
> >
> > Merged Build-Depends: cmake, debhelper (>= 9), doxygen,
> libboost-all-dev, libcharls-dev, libcurl4-openssl-dev | libcurl4-dev,
> libdcmtk-dev, libgtest-dev, libjpeg-dev, libjs-jquery, libjsoncpp-dev,
> liblua5.1-0-dev, libpng-dev, libpugixml-dev, libsqlite3-dev, libssl-dev,
> libwrap0-dev, unzip, uuid-dev, zlib1g-dev, yui-compressor
> > Filtered Build-Depends: cmake, debhelper (>= 9), doxygen,
> libboost-all-dev, libcharls-dev, libcurl4-openssl-dev, libdcmtk-dev,
> libgtest-dev, libjpeg-dev, libjs-jquery, libjsoncpp-dev, liblua5.1-0-dev,
> libpng-dev, libpugixml-dev, libsqlite3-dev, libssl-dev, libwrap0-dev,
> unzip, uuid-dev, zlib1g-dev, yui-compressor
> > dpkg-deb: building package 'sbuild-build-depends-orthanc-dummy' in
> '/<>/resolver-IyPUCn/apt_archive/sbuild-build-
> depends-orthanc-dummy.deb'.
> > dpkg-scanpackages: warning: Packages in archive but missing from
> override file:
> > dpkg-scanpackages: warning:   sbuild-build-depends-orthanc-dummy
> > dpkg-scanpackages: info: Wrote 1 entries to output Packages file.
> > Ign:1 copy:/<>/resolver-IyPUCn/apt_archive ./ InRelease
> > Get:2 copy:/<>/resolver-IyPUCn/apt_archive ./ Release [957 B]
> > Ign:3 copy:/<>/resolver-IyPUCn/apt_archive ./ Release.gpg
> > Get:4 copy:/<>/resolver-IyPUCn/apt_archive ./ Sources [476 B]
> > Get:5 

Fwd: Bug#844835: orthanc: FTBFS: build-dependency not installable: libssl-dev

[Sébastien Jodogne]

Dear all,

I have a problem understanding what is going wrong in the attached bug
report.

If I open the "debian/control" file of the "orthanc" package, I indeed see
that the package Build-Depends on "libssl-dev":
https://anonscm.debian.org/cgit/debian-med/orthanc.git/tree/debian/control

However, if I run the following session of commands, I see that
"libssl-dev" is still available in unstable:

>
jodogne@debian-unstable:~$ sudo apt-get update
Hit:1 http://ftp.belnet.be/debian unstable InRelease
Reading package lists... Done
jodogne@debian-unstable:~$ sudo apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
jodogne@debian-unstable:~$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
jodogne@debian-unstable:~$ apt-cache search libssl-dev
libssl-dev - Secure Sockets Layer toolkit - development files
<

As a consequence, I don't understand why the rebuild failed. Is it a
transient issue? Please could someone kindly give me an explanation? Thanks
in advance!

Regards,
Sébastien-



-- Forwarded message --
From: Lucas Nussbaum 
Date: Sat, Nov 19, 2016 at 7:26 AM
Subject: Bug#844835: orthanc: FTBFS: build-dependency not installable:
libssl-dev
To: sub...@bugs.debian.org


Source: orthanc
Version: 1.1.0+dfsg-2
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20161118 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> +---
---+
> | Install package build dependencies
 |
> +---
---+
>
>
> Setup apt archive
> -
>
> Merged Build-Depends: cmake, debhelper (>= 9), doxygen, libboost-all-dev,
libcharls-dev, libcurl4-openssl-dev | libcurl4-dev, libdcmtk-dev,
libgtest-dev, libjpeg-dev, libjs-jquery, libjsoncpp-dev, liblua5.1-0-dev,
libpng-dev, libpugixml-dev, libsqlite3-dev, libssl-dev, libwrap0-dev,
unzip, uuid-dev, zlib1g-dev, yui-compressor
> Filtered Build-Depends: cmake, debhelper (>= 9), doxygen,
libboost-all-dev, libcharls-dev, libcurl4-openssl-dev, libdcmtk-dev,
libgtest-dev, libjpeg-dev, libjs-jquery, libjsoncpp-dev, liblua5.1-0-dev,
libpng-dev, libpugixml-dev, libsqlite3-dev, libssl-dev, libwrap0-dev,
unzip, uuid-dev, zlib1g-dev, yui-compressor
> dpkg-deb: building package 'sbuild-build-depends-orthanc-dummy' in
'/<>/resolver-IyPUCn/apt_archive/sbuild-
build-depends-orthanc-dummy.deb'.
> dpkg-scanpackages: warning: Packages in archive but missing from override
file:
> dpkg-scanpackages: warning:   sbuild-build-depends-orthanc-dummy
> dpkg-scanpackages: info: Wrote 1 entries to output Packages file.
> Ign:1 copy:/<>/resolver-IyPUCn/apt_archive ./ InRelease
> Get:2 copy:/<>/resolver-IyPUCn/apt_archive ./ Release [957 B]
> Ign:3 copy:/<>/resolver-IyPUCn/apt_archive ./ Release.gpg
> Get:4 copy:/<>/resolver-IyPUCn/apt_archive ./ Sources [476 B]
> Get:5 copy:/<>/resolver-IyPUCn/apt_archive ./ Packages [557 B]
> Fetched 1990 B in 0s (0 B/s)
> Reading package lists...
> W: No sandbox user '_apt' on the system, can not drop privileges
> Reading package lists...
>
> Install orthanc build dependencies (apt-based resolver)
> ---
>
> Installing build dependencies
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
>  sbuild-build-depends-orthanc-dummy : Depends: libssl-dev but it is not
going to be installed
> E: Unable to correct problems, you have held broken packages.
> apt-get failed.

The full build log is available from:
   http://aws-logs.debian.net/2016/11/18/orthanc_1.1.0+dfsg-2_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

orthanc-postgresql 2.0-3

[Sébastien Jodogne]

Hello,

I have just updated the orthanc-postgresql package:
https://anonscm.debian.org/viewvc/debian-med?view=revision=22821

This new version of the package solves the severe FTBFS Bug#839309 
(orthanc-postgresql: Could NOT find PostgreSQL).

In the absence of Andreas, please someone could sponsor the upload? TIA!

Best regards,
Sébastien-

Re: Orthanc 1.1.0

[Sébastien Jodogne]

Thanks for all!

Sébastien-


> On Tue, Jun 28, 2016 at 04:32:39PM +0200, Sebastien Jodogne wrote:
> > In complement to yesterday's update of the main "orthanc" package, I have
> > just updated two of its companion plugins:
> > 
> > - orthanc-webviewer 2.2 [1]
> 
> Uploaded.
> 
> > - orthanc-dicomweb 0.3 [2]
> 
> Uploaded after `cme fix dpkg-control` which is usually the simplest
> way to get secure Vcs URLs ... and fixes other things as well.
> 
> > Would it be possible to upload them as well?
> 
> You are welcome
> 
>  Andreas.

Re: orthanc-imagej 1.1

[Sébastien Jodogne]

Dear Andreas,

> > >For me the move is not urgent if the issue above is no real problem for
> > >you.
> > 
> > OK, so I propose to move the package to Git.
> 
> Done.[1]
> [1] https://anonscm.debian.org/git/debian-med/orthanc-imagej.git

Great, thanks!

Regards,
Sébastien-

Re: Bug#820062: orthanc and orthanc-doc: error when trying to install together

[Sébastien Jodogne]

> > Indeed, I am currently running all my integration tests to be sure that
> > everything is OK.
> 
> Hmmm, why not adding these tests as autopkgtest?

Actually, running these integration tests requires a network connection and a 
Docker infrastructure. They are much more involved than the unit tests (the 
latter being called as a part of the Debian build). I also carry on some manual 
tests to be sure everything is contained in the proper DEB package.

Anyway, for those interested, the integration tests of Orthanc are publicly 
available in the following repository:
https://bitbucket.org/sjodogne/orthanc-tests/

Sébastien-

Fix for bug #818512 in Orthanc

[Sébastien Jodogne]

Dear all,

I am back from vacations.

I have just committed the fix for bug #818512 in the "orthanc" package ("FTBFS: 
Please install libdcmtk*-dev") [1]. Some Lintian issues have been fixed as well.

The new version of the package "1.0.0+dfsg-2" is ready [2]. Andreas, would it 
be possible for you to upload it?

Regards,
Sébastien-


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818512
[2] http://anonscm.debian.org/cgit/debian-med/orthanc.git/log/

Re: understanding DICOM workflow

[Sébastien Jodogne]

Hi,

> first of all: I don't expect you to work on all this, much
> less _now_.
> 
> I am mainly asking to further my own understanding and to
> assess what I can do or what I need to find someone to do.

OK ;)


> Ah, I see. So, assuming there _would_ be two REST calls
> 
>   submit_wl_entry_file
>   remove_wl_entry_file
> 
> GNUmed could (would have to) use these calls - if they
> existed - to manage the worklist content. Orthanc would use
> the worklist content to answer C-FIND requests from modalities.

Yes, that's the "GNUmed-push-to-Orthanc" possibility. It definitely makes 
sense, and the source code of the sample "ModalityWorklists" plugin can be used 
as a good starting point [1].

But, as mentioned in a previous post [2], you could also envision an 
"Orthanc-pulls-from-GNUmed" approach. Concretely, some "GNUmed" plugin for 
Orthanc would retrieve the list of worklists from GNUmed whenever Orthanc 
receives a C-FIND command for worklists. I would personally favor this 
approach, as keeping things in sync would be much more robust (the single point 
of storage for worklists would be GNUmed). But, of course, this would require 
to extend GNUmed with a REST call that would serve the list of worklists.


> > Please also note that creating a
> > plugin is really easy, that there are many examples around,
> > and that full documentation is available [1]: It would be
> > cool if someone could contribute to Orthanc by developing
> > third-party plugins besides myself.
> 
> It is beyond my abilities, however, unfortunately.

You could try and ask for help on the Orthanc discussion group [3]. Some other 
people have already developed third-party plugins.

Cheers,
Sébastien-



[1] 
https://bitbucket.org/sjodogne/orthanc/src/default/Plugins/Samples/ModalityWorklists/
[2] https://lists.debian.org/debian-med/2016/01/msg00079.html
[3] https://groups.google.com/forum/#!forum/orthanc-users

Re: understanding DICOM workflow

[Sébastien Jodogne]

> > does any of the existing plugins show how to add a REST API
> > call to Orthanc when loaded ?
> 
> Ah, I see: Samples/Basic/...
> :-)

Yes, and you can also check the following official plugins to have more 
complete sample code:
http://www.orthanc-server.com/static.php?page=web-viewer
http://www.orthanc-server.com/static.php?page=dicomweb

The DICOMweb plugin is presumably a good starting point to see how the REST 
callbacks work in the real life.

Re: understanding DICOM workflow

[Sébastien Jodogne]

> > Yes. The only problem would be to remove the worklist once
> > the device has uploaded its acquisition to Orthanc
> 
> How does that happen _now_ with the current ModalityWorkList
> plugin ? (without regard to anything I said would be useful
> from a GNUmed point of view)

The current plugin will re-read the folder for each incoming worklist request. 
It is up to the system administrator to properly sync the worklists in this 
folder using system scripts living outside Orthanc.


> I would have assumed there's two ways:
> 
>   There's a standard DICOM way of saying "remove this
>   worklist entry" (regardless of whether it is completed).

This process is typically done by sending HL7 messages, not through DICOM 
messages.

Maybe the N-DELETE from DICOM "normalized services" might be used for this 
purpose, but I'm not sure as I'm not an expert in that field. In typical 
workflows, such "normalized services" are mainly used for MPPS (N-CREATE to 
setup a worklist, N-SET to update a worklist after some acquisition). Anyway, 
Orthanc does not currently support "normalized services", as the software is 
above all designed for the workflows afterwards the DICOM image is available 
(in other terms, Orthanc is currently not a RIS).


>   Delete the corresponding *.wl from the worklist directory
>   being watched by Orthanc.

Yes, this is how it currently works. This is also the convention of the 
standard command-line tool "dcmwlm" from DCMTK.


> > (which will necessitate a custom "OnChange" callback watching DICOM
> > files entering Orthanc), or if GNUmed invalidates some
> > worklist.
> 
> I agree that there would be a need for a second REST API
> call, namely to remove a give MWL entry.

Yes. As written above, a HL7 plugin for Orthanc *could* also be written for 
this purpose, but this is probably an overkill wrt. simply adding a REST 
callback to handle HTTP DELETE.


> Wait, does the ServeFolder plugin help any ?  Does it support
> put/delete of files in the served directory ?

Not yet. As written above, it is up to the system administrator to write the 
script that will keep the content of the folder in sync.


> > However, I currently have no time to work on this extension
> > of the ModalityWorklists plugin.
> 
> Sure. Do you think I should open a card on Trello or is the
> above a wontfix from the beginning ?

You can of course add a card, but be warned that I have currently to entirely 
focus, for my employer, on a revamped version of the Orthanc Client library and 
on the support of DICOM whole-slide imaging. Please also note that creating a 
plugin is really easy, that there are many examples around, and that full 
documentation is available [1]: It would be cool if someone could contribute to 
Orthanc by developing third-party plugins besides myself.

Regards,
Sébastien-


[1] https://github.com/jodogne/OrthancContributed/tree/master/Plugins

Re: understanding DICOM workflow

[Sébastien Jodogne]

Hello Karsten,

> > I have got two questions regarding this plugin:
> > 
> > 1) Are you planning to provide something like this (pseudocode):
> > 
> > curl PUT
> > SERVER:worklist/WORLIST_NAME/worklist_file?data=data_of_worklist_file.wl
> > 
> > That way, external software (like GNUmed) can submit worklist entries.
> > 
> > or even
> > 
> > 2) Is there any chance to support (pseudocode)
> > 
> > curl PUT SERVER:server/create-worklist_entry?data={name=..., gender=...,
> > modality:..., worklist=..., ...}
> > 
> > In other words hiding the creation of a worklist file
> > behind a REST API call.

To answer your questions, it is important to understand the philosophy of 
Orthanc wrt. worklists that is described on our blog [1] :

"Serving worklists is done through the plugin infrastructure of Orthanc. The 
rationale for using plugins is that worklists are generated by mechanisms that 
live outside the DICOM world (e.g. HL7 or FHIR messages), and that are specific 
to each clinical workflow. Creating plugins allow to make the Orthanc core 
independent of these mechanisms. Note that for basic uses, we provide a sample 
worklist plugin, that reads its worklists from some directory on the filesystem 
(which mimics the "dcmwlm" tool from DCMTK)."

So, to feed Orthanc with worklists that are generated by GNUmed, the best way 
would be to develop a custom plugin that relies on the Orthanc Plugin SDK for 
worklists [2]. Using this Orthanc Plugin SDK, you could quite easily implement 
your requirement in a few lines of code. There are actually 2 possible 
approaches:

(a) The "pull from GNUmed approach". Your plugin would first register a 
worklist callback with "OrthancPluginRegisterWorklistCallback()". Your callback 
function would use the function "OrthancPluginHttpGet()" to retrieve the 
worklists through the REST API of GNUmed, and would filter the retrieved 
worklists with "OrthancPluginWorklistIsMatch()" to only keep the worklists that 
match the user's query. The matching worklists would be returned to the caller 
with "OrthancPluginWorklistAddAnswer()". This approach would have my favor, as 
the plugin would not need to store the worklists in a dedicated database.

(b) The "push to Orthanc approach" (which is what you proposed in your 
question). The idea is to replace the loop over the directory in the official 
sample plugin [3], by a loop over a set of worklists that are contained in 
memory. This set of worklists can be modified by implementing a custom REST 
callback (over the PUT, GET, and DELETE HTTP methods) with the function 
"OrthancPluginRegisterRestCallback()". In this case, the plugin needs to manage 
a local database if you want persistence.

I hope this clarifies things.

Regards,
Sébastien-


[1] http://www.orthanc-server.com/static.php?page=blog#stable
[2] https://orthanc.chu.ulg.ac.be/sdk/group__Worklists.html
[3] https://goo.gl/rQiSK6

Re: understanding DICOM workflow

[Sébastien Jodogne]

> When the ModalityWorkList plugin is loaded the Orthanc server
> gains the following capabilities:
> 
>   - watch a given path for files (which represent worklist entries in 
> DICOM
>   format)
>   - when queried appropriately, return answers based on those files
> 
> Is that correct ?

Yes.


> If so I was wondering whether the ModalityWorkList plugin
> could be extended with one REST API call which would allow
> external applications to add *.wl worklist item files over
> the network rather than having to store them into the watched
> path directly. All the ModalityWorkList plugin would do is to
> accept such files and store them into the watched path.
> 
> Sound reasonable ?

Yes. The only problem would be to remove the worklist once the device has 
uploaded its acquisition to Orthanc (which will necessitate a custom "OnChange" 
callback watching DICOM files entering Orthanc), or if GNUmed invalidates some 
worklist.

However, I currently have no time to work on this extension of the 
ModalityWorklists plugin.

Sébastien-

Re: understanding DICOM workflow

[Sébastien Jodogne]

Hello Sebastian,

I write you as the author of Orthanc [1] that you mentioned in your question.


> > What I would like to do: [typical imaging workflow]
> 
> This can indeed be covered by Open Source tools. One well-known Open
> Source DICOM toolkit is DCMTK which is developed in Germany. [...]
> These are the DCMTK tools that specifically deal with your use case:
> 
> - storescu: Send images ("DICOM Storage SCU")
> - storescp: Receive images ("DICOM Storage SCP")
> - wlmscpfs: Worklist server, serves Worklist jobs from file
>   system ("DICOM Modality Worklist SCP").
> 
> The following tools could also be interesting for you:
> 
> - findscu: Worklist client ("DICOM Modality Worklist SCU")
> - movescu/getscu/findscu: Find and download images ("DICOM Q/R SCU")
> - dcmqrscp: Image archive ("DICOM Q/R SCP"), i.e. mini PACS

Technically speaking, Orthanc is built on the top of DCMTK, which is a really 
wonderful toolkit. I am really grateful to the OFFIS team for publishing DCMTK 
under as FOSS.

Orthanc is a higher-level software than DCMTK: It can be thought of as the 
merge of all the DCMTK command-line tools that were mentioned by Michael. 
Orthanc creates a consistent REST API above these tools. It also provides a Web 
interface, a binding to database engines (SQLite and PostgreSQL), a plugin SDK 
to extend the core system, a Web viewer of medical images, Lua scripting, and 
the support of DICOMweb. Similarly to DCMTK, Orthanc is cross-platform.


> Note that if you need Storage Commitment
> (another DICOM service on top of DICOM Storage) there is no ready-to-use
> Open Source tool in DCMTK.

FYI, this feature is pending in the Orthanc roadmap [2].


> In order to get an idea how the tools work, you might read through a
> tutorial describing their use for PACS communication that I wrote
> some months ago for a research project.

Another such tutorial is available in the Orthanc Book [3]. This tutorial 
provides an introduction to DICOM through the looking glass of Orthanc.


Coming back to your original question:

> > I didn't figure out whether I can create a worklist.

Orthanc can serve DICOM worklists through its "ModalityWorklists" official 
plugin [4], in a similar fashion than DCMTK's wlmscpfs. This plugin is 
available in the Orthanc official distribution, and is installed with the 
Debian "orthanc" package. The process of creating a worklist is documented is 
FAQ #37 of DCMTK [5]: The "*.wl" files that result from this process can be 
served by Orthanc's ModalityWorklits plugin.


> > I suppose I cannot describe the findings using orthanc.

I am not sure to understand your question. There is a "--verbose" flag to 
Orthanc that will show the content of the C-FIND requests for worklists.


> > I am not sure what DICOM-storage to use for good
> > reliabilty and interoperability.

If you need reliability, use the PostgreSQL plugin for Orthanc: All the DICOM 
files and the entire Orthanc index will be stored as a PostgreSQL database, 
that is enterprise-ready with advanced backup possibilities [6].

Thanks to its internal use of DCMTK that is very widespread in the industry, 
Orthanc provides good DICOM interoperability.

Of course, if you need more information about Orthanc, do not hesitate to get 
in touch with its community [7].

Regards,
Sébastien-


[1] http://www.orthanc-server.com/
[2] https://trello.com/c/wyVJMJrS
[3] https://orthanc.chu.ulg.ac.be/book/dicom-guide.html
[4] 
https://bitbucket.org/sjodogne/orthanc/src/default/Plugins/Samples/ModalityWorklists/
[5] http://forum.dcmtk.org/viewtopic.php?f=4=84
[6] http://www.orthanc-server.com/static.php?page=postgresql
[7] https://groups.google.com/forum/#!forum/orthanc-users

Fwd: orthanc REMOVED from testing

[Sébastien Jodogne]

Dear all,

FYI, orthanc has just been removed from testing.

But, the bug that justifies its removal from testing is fixed since November 
10th, 2015:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804571

Is there something that remains to be done to migrate new versions of orthanc 
to testing?

Merry Christmas!
Sébastien-



- Mail transféré -
De: "Debian testing watch" 
À: orth...@packages.debian.org
Envoyé: Jeudi 24 Décembre 2015 17:39:08
Objet: orthanc REMOVED from testing

FYI: The status of the orthanc source package
in Debian's testing distribution has changed.

  Previous version: 0.9.4+dfsg-1
  Current version:  (not in testing)
  Hint: 
Bug #804571: orthanc: build-depends on libdcmtk2-dev which is no longer 
built

The script that generates this mail tries to extract removal
reasons from comments in the britney hint files. Those comments
were not originally meant to be machine readable, so if the
reason for removing your package seems to be nonsense, it is
probably the reporting script that got confused. Please check the
actual hints file before you complain about meaningless removals.

Re: Orthanc plugins

[Sébastien Jodogne]

Hi Andreas,

> You are welcome.  Just tell me if you want me to migrate also the
> remaining orthanc-* packages.  For me the migration is not that
> urgent since there is no change of the original tarball needed but
> you might be interested to use a single VCS - so just let me know.

Actually, I don't mind using Subversion or git, this is really as wish.


> > As it is the first time I play with git-based Debian packaging, could you
> > validate my modifications and upload them if everything is OK?
> 
> Yup.  OK and uploaded.

Fine! 

I released today the first stable release of Orthanc (version 1.0.0). I have 
updated the git repository of Debian Med with this new version. Could you once 
again upload it?

Sébastiens-

Re: Orthanc plugins

[Sébastien Jodogne]

> > I released today the first stable release of Orthanc (version 1.0.0). I
> > have updated the git repository of Debian Med with this new version. Could
> > you once again upload it?
> 
> Uploaded.

Thanks!


> PS: May be you might consider becoming a Debian Maintainer.  I think
> you are able to maintain those five packages on your own without
> any sponsor.

Thanks for this proposal... unfortunately, I still have not been able to talk 
with a Debian developer who could sign my key.

My key is submitted for the keysigning event at FOSDEM 2016 [1,2], where I 
should hopefully meet someone from Debian.

Regards,
Sébastien-


[1] https://fosdem.org/2016/keysigning/
[2] https://ksp.fosdem.org/keys/A776582B312AC35D

Re: Orthanc plugins

[Sébastien Jodogne]

Hi Andreas,

> > I have just upgraded all the Orthanc plugins:
> > - orthanc-webviewer: version 2.1
> > - orthanc-postgresql: version 2.0
> Both done.

> > - orthanc-dicomweb: version 0.2
> Moved to Git since stripped orig.tar.xz and uploaded.

Great! Thanks for the uploads and for the move to git of orthanc-dicomweb.

I have also updated the main "orthanc" package to version 0.9.6:
http://anonscm.debian.org/cgit/debian-med/orthanc.git/

As it is the first time I play with git-based Debian packaging, could you 
validate my modifications and upload them if everything is OK?

Thanks again,
Sébastien-

Orthanc plugins

[Sébastien Jodogne]

Hello,

I have just upgraded all the Orthanc plugins:
- orthanc-webviewer: version 2.1
- orthanc-postgresql: version 2.0
- orthanc-dicomweb: version 0.2

Andreas, would it be possible for you to upload these new versions? Thanks in 
advance!

Regards,
Sébastien-

Re: Orthanc 0.9.5

[Sébastien Jodogne]

Hi Andreas,

Thanks for your help! I will try and play with the git-based orthanc package 
asap.

Please note that I have just updated "orthanc-webviewer":
http://anonscm.debian.org/viewvc/debian-med?view=revision=date=20631

Would you kindly upload it? An updated version of "orthanc-postgresql" will 
also follow in the next few days.

Cheers,
Sébastien-



> On Thu, Dec 03, 2015 at 09:15:52PM +0100, Sébastien Jodogne wrote:
> > 
> > AFAIC, there is no problem to switch the source of the "orthanc" Debian
> > package from SVN to git... but, indeed, I will not be able to make the
> > migration by myself. Please could you bootstrap the process?
> 
> Done for orthanc.  For future updates make sure you always import via
> 
>gbp import-orig --pristine-tar
> 
> to make sure the tarball is injected as well (see Debian Med policy for
> details).  I personally do not mind about the other orthanc-* packages
> since here we are using the original tarball but let me know if you want
> to use Git instead of SVN as well.

Orthanc 0.9.5

[Sébastien Jodogne]

Dear all,

I have just updated the DebianMed repository with the newest upstream version 
of Orthanc (0.9.5) [1].

Andreas, if the package looks OK to you, please would you kindly upload it? 
Thanks in advance!

Cheers,
Sébastien-


[1] 
http://anonscm.debian.org/viewvc/debian-med/trunk/packages/orthanc/trunk/debian/?sortby=date#dirlist

Re: Orthanc 0.9.5

[Sébastien Jodogne]

Hi Andreas,

> > I have just updated the DebianMed repository with the newest upstream
> > version of Orthanc (0.9.5) [1].
> 
> Uploaded.

Thanks!


> Remark: My personal policy is to migrate those packages that are using
> orig.tar.?z archives which are not byte identical with what is
> downloaded from upstream (for instance due to the removal of files like
> JS as in theorthanc case) from SVN to Git.  This has the advantage that
> the orig.tar.?z is in pristine-tar branch and sponsor and sponsee are
> working on the very same file.  What do you think about using a Git
> repository for the maintenance of orthanc?  I'd for sure volunteer to
> migrate the current state since I have quite some experience in doing
> this.

AFAIC, there is no problem to switch the source of the "orthanc" Debian package 
from SVN to git... but, indeed, I will not be able to make the migration by 
myself. Please could you bootstrap the process?

Cheers,
Sébastien-

Orthanc - fix bug #804571

[Sébastien Jodogne]

Hi Andreas,

I have just fixed bug #804571 that was reported yesterday on Orthanc [1,2].

Would it be possible for you to upload this new version (0.9.4+dfsg-2)?

TIA,
Sébastien-


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804571
[2] http://anonscm.debian.org/viewvc/debian-med?view=revision=20477

orthanc-postgresql 1.3

[Sébastien Jodogne]

Hello,

I have just updated the repositories with the latest upstream version of the 
PostgreSQL plugins for Orthanc [1]. This minor release notably fixes build 
problems against orthanc-dev 0.9.4.

Andreas, please would you consider this update for upload?

Thanks,
Sébastien-



[1] http://anonscm.debian.org/viewvc/debian-med?view=revision=20202

FOSDEM 2016

[Sébastien Jodogne]

Hello,

In the improbable case you missed the information, please note that the FOSDEM 
2016 call for participation is available [1]. The deadlines for submissions are 
as follows:

- Developer rooms: October 9th.
- Main tracks: October 16th.
- Stands: November 13rd.
- Lightning talks: November 27th.

Regards,
Sébastien-


[1] https://fosdem.org/2016/news/2015-09-24-call-for-participation/

Re: C++ help needed for Tide

[Sébastien Jodogne]

Hi,

> g++ -ggdb -O6 -DNDEBUG -I./protoobj -g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security -o obj-opt-x86_64/test_spectrum_preprocess.o -c
> src/test_spectrum_preprocess.cc
> In file included from src/test_spectrum_preprocess.cc:8:0:
> src/records.h: In destructor 'RecordWriter::~RecordWriter()':
> src/records.h:85:16: error: 'close' was not declared in this scope
>close(fd_);
> ^
> src/records.h: In destructor 'RecordReader::~RecordReader()':
> src/records.h:137:14: error: 'close' was not declared in this scope
>  close(fd_);
>   ^
> 
> Any help would be welcome

Simply add at the top of "src/records.h":

#include 

You'll also have to add at the top of "src/search.cc" and "src/peptide_mods.cc":

#include 

And finally at the top of "src/modifications.h":

#include 

HTH,
Sébastien-