On Tue, Apr 22, 2025 at 07:26:04PM +0200, Sébastien Jodogne wrote:

Dear Mentors,

I am currently facing I am unable to solve by myself.

The dcmtk migration from 3.6.9-4 to 3.6.9-5 is currently blocked
because of orthanc and some of its plugins [1]. Looking at orthanc,
its migration status from 1.12.6+dfsg-1 to 1.12.7+dfsg-2 is: "BLOCKED: >Rejected/violates migration policy/introduces a regression" [2].

Unfortunately, even after locally compiling dcmtk_3.6.9-4, I am unable
to reproduce the build errors that are reported by the continuous
integration server [3]. On my machine, everything compiles and
executes fine.

Besides, are you sure you understand the difference between building the package and running autopkgtests for it?
autopkgtests for orthanc 1.12.7+dfsg-1 fail for me locally.

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmgH4fotFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh VhsP/2/EwPCSd5XZie1LEQWSvCXYwGAeAkfSFZNo+MmUtnU8JhDmQXY6OhDYlhTa ydU1ELpf4TH0m+MtetDAMVi13Ag5VBXEnzgNO/N6hhEa6XitpxXgeAuNQtOKsCTv XEk094D/0GQ5jmaYMgHFmlIcXjBRAYB9eioJ+eS/dxgT+tBESh40qDZ3NxH0JkWc iM2sbNHGEKwWK8jINhT2sB7Xr+SXgaqpg2ySRe8jLpDZfamoP15idHEXc1p3p+L5 1b1b6nz2fUxGo+YXevLzbJYNN32QKUvGzLmOqr+9fabMRumwzubXqXbIz7AD7eun xP5rWLHL5v+aJTmoomxHtq1u2DydVFkLdrw17akhRrySqPIDnpTmZcSjArJ01cfi 7Zs++Zz1IeGwOGkvGzj13PsVKGWCyZxmVdfj8Ytmn4B2UAiB7bSVv4z97i1WndRL bk/c/YUNLe0eiUkP3geNQyklk/MMcmA+qLAzlwbtg0j/1JCn02tGg1pevzq3RVqk e/6lpCVUC3olwC2kKkvMBREbic57oJ0y7B4MLzYJ5azs0wBBano4uOW0PdKG6IGL ZjIS6R0tplF9fvyR756wuSM3hPjT+YSCNGzGI2p1offr1Gx++hSuZ/EhqsyzoV0t og1oLtC4QrANrm9JsrGmhw9KC4Cb1WDhSpnVWlpnNGDdXkIh
=QooZ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Apr 22, 2025 at 07:26:04PM +0200, Sébastien Jodogne wrote: >Unfortunately, even after locally compiling dcmtk_3.6.9-4, I am unable

to reproduce the build errors that are reported by the continuous
integration server [3]. On my machine, everything compiles and
executes fine.

Please someone could help me reproduce this compilation error on my
computer? Without this information, I won't be able to fix the issue.

I don't see any "build errors" / "compilation error" there. Can you
elaborate? Are you looking at some wrong logs, not the ones you linked?

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmgH3gYtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh aDgP+gPtRccAe6rVhzkGvZuh9GPt+Vqd2Q/GWbf0A5MGABD+V2DFCndfZNmK5e3i oY5ww+gKyAfgqREp/Ricu0nma89jOxiGszu+wqOHo/pYArJiSEOMYlrJiwB29X4u bfnwdDFx6MoaIMn01xnlv2bJhtNpmYnD+nIU/7RJzq6bsO1IeKu3oUpQy9VFgoZL uHxaFs9n1XlO2jP5nY+QQdCJIyFyCzqWCpC2emtfOxF69AbKFN/3NntRBTmDNAZQ S/yH5k/QcVlPBiLLhXCHDIcizUbVuTdpw/JywfwOjDZM2yf9/2KSCxb+sg5OBpWH gYvTy08AtiYwPnCxNj7yEemc0m6Wuej4pPxCujEw4KIMpj0QQ+oh7O1YVNJzRi7A /jLODAhAUjw2LJeUvIQWawiA5BZsoMXiXmV1XQz86FZGafz5iAcHI36gVTTH3T4e K5zRa3PxRE6pZEUF1egbzmWq4Jx5QGIlx8X0orT1xOfeVsOH3bJP8GFJH/sM061E Ts+pvfgVrvDrwyT+1DfOWL23IZF95Z39TWgO1NV3FWA1r55MTDMqIz0N+YTqKydF DUu711I1EqA5sv7n02QAnCYMEi+MmhVwkVG39qmeYEjf+CNBnZZ3Plz0HORSIlfg mAQWicxRFaw+jTr2ZI012AvSSZCSnqgydJFTYGndAevPhJ0D
=tVXK
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Sébastien,

First of all, thank you for having promptly followed up with
mitigation to issues appearing in the Orthanc suite since dcmtk
upload! I think I have identified the root cause of the problem
in orthanc autopkgtest to be resolved with the following logic,
which allows for the first few attempts to fail with non-zero
exit codes, without dropping off the script unconditionally:

-------8<--------------8<--------------8<--------------8<-------
--- a/debian/tests/run-test
+++ b/debian/tests/run-test
@@ -38,6 +38,7 @@ fi
# Try for 15 times to find the system REST API of Orthanc up and running
URL=http://localhost:8042/system
tries=15
+set +e
while true
do
STATUSCODE=$(curl --silent --output /dev/null --write-out "%{http_code}" ${URL})
@@ -46,6 +47,7 @@ do
test "$tries" -le 0 && echo "Unable to initialize Orthanc" && exit 1
sleep 1
done
+set -e


URL="http://localhost:8042/app/explorer.html" -------8<--------------8<--------------8<--------------8<-------

I have verified the patch resolves the problem for your orthanc
package. A similar approach will do the job for your package
orthanc-wsi, but I also noted the run-dicom-image-transcode-test
will also need to depend on curl to operate properly.

In hope this helps,
--
.''`. Étienne Mollier <[email protected]>
: :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/2, please excuse my verbosity
`-

On Tue, Apr 22, 2025 at 09:05:39PM +0200, Sébastien Jodogne wrote:

The "orthanc" service fails to start properly, and I suspect (but I am
not sure) that this is related to an issue with the
"/usr/share/dcmtk/" path,

It would be nice to see an actual error message pointing to that, but if
you think this is the reason, you already know the solution from the
replies to #1103505: you need to add suitable Depends/Breaks so that
CI doesn't try to test package combinations that are not expected to work together.

autopkgtests for orthanc 1.12.7+dfsg-1 fail for me locally.

The latest version is orthanc 1.12.7+dfsg-2

Indeed.
However, autopkgtests for orthanc 1.12.7+dfsg-2 fail for me locally with
the same output as 1.12.7+dfsg-1, though I now see that the output is different from the CI one:

Setting up orthanc (1.12.7+dfsg-2) ...
Generating locales (this might take a while)...
en_US.UTF-8... done
Generation complete.
invoke-rc.d: could not determine current runlevel
All runlevel operations denied by policy
invoke-rc.d: policy-rc.d denied execution of start.
invoke-rc.d: could not determine current runlevel
All runlevel operations denied by policy
invoke-rc.d: policy-rc.d denied execution of start.
Processing triggers for libc-bin (2.41-7) ...
autopkgtest [00:28:38]: test run-test: [-----------------------
User 'orthanc' exists.
Orthanc is active.
autopkgtest [00:28:38]: test run-test: -----------------------]
autopkgtest [00:28:38]: test run-test: - - - - - - - - - - results - - - - - - - - - -
run-test FAIL non-zero exit status 7
autopkgtest [00:28:38]: @@@@@@@@@@@@@@@@@@@@ summary
run-test FAIL non-zero exit status 7


It seems that it simply exits via set -e when your new curl invocation
fails.


--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmgH9jctFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh y5wQAJJW9MpZaYkntIIJEZC8nYRzBXa2nWaPUgFObPPKCJpOcWXVerxZT6Ql8MhS OMIzsySIILjz3lFEDBxCyrW19HWsOJ08h0c1z5Cmv2eJ0a2lO6UQGDSagnXZkyxH do7hfVm7Z/fDjMOASOL/cezqu39PzL82QWC3kI2yYWMLN3zTe3bBS1cLnOwbo1nE AboeCrz1FL324Sk7ka/jyENugY+hCXDgQfHD0Cij+hwFOtYs2w23+Lr7PNUmgjrl oE8GQW2TgM8jNVkmbRtk23QQeevmsIzrv/ap9DrRz4B9BitO2ZnF8QWTi3OdKQbi Dk2+yjMSQtcGyJHJJYoUyTrBvT3QRmqTcoHykp3zGqTwWCwiXIIhAxct5q21GbTY iA1AysREh4zUtVPNQiThZhLAyKnjeBVv8cKw0VCzF1zIqubLD/4Xpac2drfjdOxs lV3Too/VVw9J76bMunchHLOuarmfJx5D+OzlUwARcFrCG/OYXGagko5a2muzL5Hb aDuxZQb04RfHoaQA9bkYf9/ebOGc1Wc/kJLwrPPW1E7oFVDa8zTP89UFJ8ouRTHh +XO4TIvqzVda9AHijo4xMPzgCA4UHrEOerNDmpQ+LBAk8whY11JA/KsriDK2jUgP 3fVjF4HE5Czx/5UFTmhjc9+dTnODWYgx4IP2FLhRDiUG2kIp
=G3eQ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dear Andrey,

Thanks for your quick feedback.

I don't see any "build errors" / "compilation error" there. Can you elaborate? Are you looking at some wrong logs, not the ones you linked?

Sorry for my lack of clarity: The compilation does succeed, but running autopkgtest doesn't.

Besides, are you sure you understand the difference between building the package and running autopkgtests for it?

Yes, I confirm that the issue is with autopkgtest, as can be seen in the
logs of the integration server: https://ci.debian.net/packages/o/orthanc/testing/amd64/60205947/

The "orthanc" service fails to start properly, and I suspect (but I am
not sure) that this is related to an issue with the "/usr/share/dcmtk/"
path, which is more apparent in the autopkgtest results of the related
package "orthanc-wsi": https://ci.debian.net/packages/o/orthanc-wsi/testing/amd64/60205953/

Excerpt:

21s W0422 15:17:45.182985 7f0961bdda00 FromDcmtkBridge.cpp:383]
Loading external DICOM dictionary: "/usr/share/dcmtk/dicom.dic"
21s E: DcmDataDictionary: Cannot open file: /usr/share/dcmtk/dicom.dic

However, this issue should first be solved in "src:orthanc", as "src:orthanc-wsi" depends on the orthanc package.

autopkgtests for orthanc 1.12.7+dfsg-1 fail for me locally.

The latest version is orthanc 1.12.7+dfsg-2 and was committed this
morning with a fix that might solve the build failure you have just
encountered with 1.12.7+dfsg-1: https://salsa.debian.org/med-team/orthanc/-/commit/4ae57af5a89e62584bab32b53af71bfdd13722a1

Note that I thought this commit should have fixed issue #1103504, but
this was not the case, so "d/changelog" is currently incorrect.

Before uploading, I evidently checked that pbuilder and autopkgtest were
both OK.

Regards,
Sébastien-

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Sébastien,

The question now is: What can be done? I guess that the proper solution
would be to "unblock" dcmtk 3.6.9-5, but is it true and, if so, how would this be feasible?

Once the autopkgtest failures are resolved in unstable (see my
other email to d-mentors), I believe it will be reasonable to
unlock the situation by opening an "unblock" request to the
Release Team using:

$ reportbug release.debian.org

Have a nice day, :)
--
.''`. Étienne Mollier <[email protected]>
: :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/2, please excuse my verbosity
`- on air: Brand X - The Ghost Of Mayfield Lodge

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEj5GyJ8fW8rGUjII2eTz2fo8NEdoFAmgH9lgACgkQeTz2fo8N EdquLBAAjSgkS3/4evVaORVtp5bWbmGXjK9tGuFYe6bqAqDBh+KpOvwySmC0Avdo aGdDWPdkePTvHeJ+Klr3I5qsOUvH0IbLQZDm8LPwSjwDzZvYwH4y8Byw93TtmEUf IzCOetd1O4QcU+/FkVD3lra/pjZKSP24kUY7xdDw/vD9bTTkLV+OBC6uJRykrbq7 UnEWXuJ1ge28K17ZlRrvX3/np/81hbGUZSyAH4oYWI3rC2HxiX/xg4wcJ6VSvV7J 607/8p5SQOlN/qcu2OAm0UX3kEtKSzyFqwtscn/XeTY+5tCC1/1HPpySSsRHVESe PjLpTdLM7GpeDHCEj9BHTiwcMRMUJ8KlyyuX1Jbks8LY1Y/zSI5jqt5rwqmYHHUN 0hZkEyb2yN+1q6dt6V36Zaw+UlxnFnncJeDT4p1Zs2/58h+UZ/Ei7LpGmErqRwpD O0pnlVTQZHxNOKxJ2kJXNOyYeBmiKpNDzq8Sxl3RLCtR3jP/z2qnh1P2Uw02ssH7 KdjSjx/4Jv+Ikmq3/TosHsYZXwNutfjnoDAWiNNCX/sN29EfpiwDfaa1uRBRvKvD XM2WOqQrT9b/L8L4lM/V9gFhUmiVHbWamXn7TVhIdcWkwm2fWahrahHRlNyVvJaH /5XghO9JYzS6fRlvJVDgfdp+JHm9

Hi Andrey,

On Tue, Apr 22, 2025 at 10:04:40PM +0200, Étienne Mollier wrote:

Hi Sébastien,

The question now is: What can be done? I guess that the proper solution would be to "unblock" dcmtk 3.6.9-5, but is it true and, if so, how would this be feasible?

Once the autopkgtest failures are resolved in unstable (see my
other email to d-mentors), I believe it will be reasonable to
unlock the situation by opening an "unblock" request to the
Release Team using:

$ reportbug release.debian.org

Soft freeze doesn't require manual unblocks.

I have been concerned by entanglement between dcmtk and orthanc,
but if appropriate versioned dependency relations are in place,
as you suggest, then I guess this resolves my concern. Thanks!

Have a nice day, :)
--
.''`. Étienne Mollier <[email protected]>
: :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/1, please excuse my verbosity
`- on air: Cairo (US) - Angels And Rage

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEj5GyJ8fW8rGUjII2eTz2fo8NEdoFAmgH+LUACgkQeTz2fo8N EdrvjxAAqAE9AZlF0Pt1eIdI/gj7BiLpbukh7V7ATWfvAOmWJjsXMmjrxdn8ye4r ZeUNhToz1NedyjV8lv2zAlpC/CptYDSppJM88Cs3f4yDoUl7342BrFmtL2nOGPCd xYt4x2na2HwItE07ZNKuRTdCT/Y+14FCSy9y8BUZ0HI0wPqy02CadZPoYwa4O1pm OP2eTUzYoz4dg/6elguQi5bVt/O9Bm1UYL8TG7sC/lCBH89AhUDRAtE9Id7mDw/m WMRqT40R3+s7K+5j+URf6RNxZXj1+jH/v2vI4WaGPk/IUvzxFQRJEgOMM7HOQyL+ YGqb8E3TINVSrHvBcTgld4jrvywlt3owgOgNbMsSBn6aOvwgB0TOibIJT8vVQiVC yXUTghkDYGU0bAmjClpZbZ5wKt/afgPxi57aTjkx7O1DGYMe+z3e3KOO3NZ7PvCf z8krm5TkuPAy2TzJpdSjRb7983tbjbXavD0n98MEqehkCvsv+QmgFsaL80S3y+lf tFvHLz7n8QZOBsBwLh/iKEI8+y6xKTuVeSEzcia9tfMPbeEn7KgqVgOnqZDcqMdU CA+Zybm5xJkR/7VXKh1AkPIMPEjQfC2UhFpjphhDssNOGE+AZZQ/W/AnaG3p1VWK DvDp6SGtMSxK/a39OZAsg1lsIuUnav7mkzKAa

Hi Étienne,

Thanks for your help, nice catch!

The problem was visibly that I copied/pasted the code from another
package that was not using "set -e" at the beginning of the script.

I am now in the process of making a new release in unstable. I'll then
try and use reportbug to unblock (I've never done this before...).

Best,
Sébastien-

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Apr 22, 2025 at 10:04:40PM +0200, Étienne Mollier wrote:

Hi Sébastien,

The question now is: What can be done? I guess that the proper solution
would be to "unblock" dcmtk 3.6.9-5, but is it true and, if so, how would
this be feasible?

Once the autopkgtest failures are resolved in unstable (see my
other email to d-mentors), I believe it will be reasonable to
unlock the situation by opening an "unblock" request to the
Release Team using:

$ reportbug release.debian.org

Soft freeze doesn't require manual unblocks.



--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmgH99ctFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh AsgP/10VhI3qIDNyzxDHOCi99VN+ogLWkOnBG8tIV7CbmBAoAhhXkPVEDnB1MEIU UQsn+IvPwF2NvOvGcrVJYT83E/1m40th0u07+6Mar42utKM52711mIBHgdczjBkJ dQ5fv2HcXVnmg2aEDCKcikjM7lS7t//M+VcUhwmLBDB0anEcKmVmAgI1a8/zEfz7 BqCFEo31EFZEkJrxb1jb56xKQzUrNcNptOKfJrrCoqERRZXZhDGrdBr4PlskBTu5 Y8mgXubdBejRf3cKuaWvQ0CKJM6YzFTTNmWOgvQ0sy2kJbW+3BryuEOXoNDMSwi7 gxj4H8PmgAmovQOHeEKICaN089MZa+CIm52zziblBY7tNK8Pp3XyXUrBkRTfmH2C rh7lx/QA2oh9T4RTIIzQQ6lx/2PXt3d7K15dLgjIMJtMxtpYvMNmsGqHAIjVBTi7 aPNTJsSMoEDqmrESDm2jA3ZifRC1x2DfY6wR/3zyQR/pdm4kq5mnuDKTo5K2nwqT pDFdeVWA1/I8aX2+6G6Pfl1EWVYqYdSgihIxpqRKU3KAacLTHtay7+zSBm35zY0D w6Ysi0+M7LFPJQHt0hGPBm00e2IMJdBjUxRNj3DDdYUEYZ299dMGf7iZH4foJfjg N/nBtr6DUt0C9gRDDnhV4gOJz4N0DOT4D3btnsAo3SoteWLe
=zbyL
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Apr 22, 2025 at 10:24:17PM +0200, Sébastien Jodogne wrote:

The problem was visibly that I copied/pasted the code from another
package that was not using "set -e" at the beginning of the script.

That's usually a bug. But whatever.

I am now in the process of making a new release in unstable. I'll then
try and use reportbug to unblock (I've never done this before...).

As I already said, there is nothing to unblock here via reportbug.

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmgIlzktFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh XIIP/RybPOc2EgMyV7iI9ShyKovkBoltTQO+omgz3N+TJiooAInGnokE3r5e0/uh cXs9RWSMWY5K29UbAsJ10/MOHr7aPHzsqGuhj/Df5ZtlNH36PJp989vt8ZsPj2zC KptCg1Xm8C52igpZ5zTGNPQivhJiHeEZzfyV7PYmFg6CbU0cvgYCK+MABwhNpuSX 2jNcqDXXXQ5DkN7TKSPjebE7iUrOyCSMDxGK0Frz3i4ITWzfTnSmmVlde+njPXPv 2Uwa4MWJynHk+pzg74OPDwnKde089X49uh2kIQojXj+ImbPczyy1SGwnItd0M937 mIZRUEZRVlv+7ET+5Mh0152rUOUA88HibPm7+AnZZ1sYSYMFVn9/SIk4L+JMkUvz sxU3BRG54mWXLLeo5k6iVbu0QUZ/oj/wEo8Fq+CS/M6Qs4gdRJvcSu9+OeR+uwbQ ThQlk2UeVUl7mUY3MXNr+vP4JlbAR3ZiyElwl8jb9B+f/a6iQV/GM61gUskaB9nO 9H5gdjpglRzcXXVEDPaam3PpsKMD9kbdhbMI3gIJ/PmLzQCZRexLz8/dEv7yGWbj V2oXUlR5JyllDJWyLX2Dk3wPeF08AZpCBVuqZW4COZPAPCusKNbnRLsvkemL26rl nyUc80EvkFFpQPhnnRjBv1qBRgxl5FSzQ44yZLTw1uk4EAdt
=OlHj
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Sébastien,

For information: I am working on implementing the suggested
dependency specifications in order to disentangle the test
failures still observed in testing, caused by mismatches between
older dcmtk or older orthanc versions. I have pushed some
changes on Salsa to orthanc, orthanc-wsi, and orthanc-python, as
they shown regressions with orthanc 1.12.7+dfsg-3[1].

[1]: https://qa.debian.org/excuses.php?package=orthanc

I let continuous integration run. If all goes well I plan to
team upload later in the evening. Hopefully the situation will
be a bit clearer tomorrow as the dust settles.

Have a good evening, :)
--
.''`. Étienne Mollier <[email protected]>
: :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/5, please excuse my verbosity
`- on air: Kaipa - Songs in Our Hands

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEj5GyJ8fW8rGUjII2eTz2fo8NEdoFAmgJPigACgkQeTz2fo8N EdpbaxAAgW69CqWA82a7nln55vQKzj1gKdhBwzHghyqOuWidwaRftTD+AHtBrerV izDccyIYylUTA03P+rLl6wZ0PqSYx70I98H6GYJxdt9rJBQGWbdRCicwJMwLJBXt mzjUqYwa8LXMW0Pm8IdRcP8oE5fBdrQ0IaQna5C44ed3UmBJLd9KjZDvZvQAtOpW xuyGSexMzVfTk58B1nbQMzou+6QrzNleQm93ZksnhoYgEYLUbGDCfFmlHWLC5gpw yONoXcnvkAVCJGYZQv3fLRtc19JJn9I0e53I+CDj0kSwWW1gDDySYU0QsnIm/TeI T22AN0wNq6QeBUH+4vm4An9e4m/4mLHbKlCd2fZ0+DQAMOCTVGHzTfsOQtFloTLn ewVwcVwB45zhsW1BzyJSvG9nypqSs2Gl7Ce7bbK/uNO83bQ1iQUX1JcYhoV2XElS Rg+J+nQSfFYZ6/HUOoA5jaJHyHCGLzfgy9ZNIAxj5aInM2C7POM+93jcWILJY9Uh VlBwDfyTk0sEiB9Yx45Uoomc3gacN0tgbkl4Fc/ArMkzQsKS96RwJCBkC2F25HsT c2Je+mEl672w8Jc0Uuq5gsFoOZCV3JcKegnuK870w0rUp3OOH8p0GEGZSFSnGr1g ym/x9P0U1Nf+sZtEXabVgUCKc7uaz3P96/Z8rgz