Bug#1041813: orthanc: test failing on s390x

2023-08-12 Thread Sébastien Jodogne

Dear Étienne,

Thanks for your investigation! I confirm that you have found the proper 
way of fixing this issue.


I have just committed an adapted patch in the upstream project, which 
provides better compatibility with non-GNU/Linux environments:

https://hg.orthanc-server.com/orthanc/rev/91b3154bd4e1

Kind Regards,
Sébastien-


On 11/08/23 19:55, Étienne Mollier wrote:

Étienne Mollier, on 2023-08-11:

I have been devising on the orthanc test failure on big endian
systems referenced in Debian Bug#1041813, and I came up with the
patch in attachment.


The patch is in attachment for real this time.  (:




Bug#1041813: orthanc: test failing on s390x

2023-08-11 Thread Étienne Mollier
Étienne Mollier, on 2023-08-11:
> I have been devising on the orthanc test failure on big endian
> systems referenced in Debian Bug#1041813, and I came up with the
> patch in attachment.

The patch is in attachment for real this time.  (:
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/0, please excuse my verbosity
   `-on air: The Neal Morse Band - Not Afraid Pt. 2
Description: swab Color16Pattern
 This patch creates new source data for big endian systems, fixing test
 failures on systems such as s390x.
Bug-Debian: https://bugs.debian.org/1041813
Author: Étienne Mollier 
Last-Update: 2023-08-11
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- orthanc.orig/OrthancFramework/UnitTestsSources/ImageTests.cpp
+++ orthanc/OrthancFramework/UnitTestsSources/ImageTests.cpp
@@ -91,6 +91,7 @@
   unsigned int pitch = width * 8;
 
   std::vector image(height * pitch);
+#if ( __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ )
   for (unsigned int y = 0; y < height; y++)
   {
 uint8_t *p = [0] + y * pitch;
@@ -106,6 +107,23 @@
   p[7] = (y % 8 == 7) ? 255 : 0;
 }
   }
+#elif ( __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ )
+  for (unsigned int y = 0; y < height; y++)
+  {
+uint8_t *p = [0] + y * pitch;
+for (unsigned int x = 0; x < width; x++, p += 8)
+{
+  p[0] = (y % 8 == 1) ? 255 : 0;
+  p[1] = (y % 8 == 0) ? 255 : 0;
+  p[2] = (y % 8 == 3) ? 255 : 0;
+  p[3] = (y % 8 == 2) ? 255 : 0;
+  p[4] = (y % 8 == 5) ? 255 : 0;
+  p[5] = (y % 8 == 4) ? 255 : 0;
+  p[6] = (y % 8 == 7) ? 255 : 0;
+  p[7] = (y % 8 == 6) ? 255 : 0;
+}
+  }
+#endif /* __BYTE_ORDER__ */
 
   Orthanc::ImageAccessor accessor;
   accessor.AssignReadOnly(Orthanc::PixelFormat_RGBA64, width, height, pitch, [0]);


signature.asc
Description: PGP signature


Bug#1041813: orthanc: test failing on s390x

2023-08-11 Thread Étienne Mollier
Control: tags -1 + patch

Hi Sébastien,

I have been devising on the orthanc test failure on big endian
systems referenced in Debian Bug#1041813, and I came up with the
patch in attachment.  However, I'm not sure I'm fixing the issue
at the right place, or just hiding the problem below the carpet,
as the problem could either stem from:

  * the input test data (this is what the patch adjusts),
  * the reference output data (I assume this must be left
untouched in this case),
  * the function being tested (I think this is also a very valid
place, but it depends on the architecture of orthanc source
code, in which I haven't dug long enough at all to determine
whether this is the correct place indeed).

In hope this helps, even if this is not the right approach in
the end, have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/0, please excuse my verbosity
   `-on air: The Neal Morse Band - Not Afraid Pt. 2


signature.asc
Description: PGP signature


Bug#1041813: orthanc: test failing on s390x (skipped)

2023-07-23 Thread Étienne Mollier
Source: orthanc
Version: 1.12.1+dfsg-1
Severity: important
Tags: upstream

The orthanc test suite fails after the build on s390x:

./OrthancFramework/UnitTestsSources/ImageTests.cpp:124: Failure
Expected equality of these values:
  "1cca552b6bd152b6fdab35c4a9f02c2a"
  md5
Which is: "92186150927d2f2c883ea72155597056"
[  FAILED  ] PngWriter.Color16Pattern (4 ms)
[…]
[--] Global test environment tear-down
[==] 270 tests from 63 test suites ran. (2030 ms total)
[  PASSED  ] 269 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] PngWriter.Color16Pattern

 1 FAILED TEST

This test is currently skipped in version 1.12.1+dfsg-2, but I
proceeded pretty bluntly, so at least the skip should be big
endian specific, or better the root cause should be fixed.

From my current investigations, the resulting png image from the
PngWriter.Color16Pattern shows two problems:

 1. it can't be opened by image viewers, but it is indeed
recognized as a PNG by file(1) and examining it with an
hexadecimal editor doesn't raise any obvious issues (apart
that they are different);

 2. analyzing the images pixel per pixel using sng(1) highlights
the image itself is byte swapped compared to the image
produced on little endian system; this is very visible when
using side by side comparison on the sng files:

$ diff --side-by-side --width=80 Color16Pattern_amd64.sng 
Color16Pattern_s390x.sng | head -n20
#SNG: from Color16Pattern_amd64.png   | #SNG: from 
Color16Pattern_s390x.png
IHDR {  IHDR {
width: 17; height: 61; bitdepth:width: 17; height: 61; 
bitdepth: 
using color alpha;  using color alpha;
}   }
IMAGE { IMAGE {
pixels hex  pixels hex
00ff 00ff 00f <
ff00 ff00 ff0   ff00 
ff00 ff0
00ff 00ff 000 | 00ff 
00ff 00f
ff00 ff00 000   ff00 
ff00 000
00ff 00ff 000 | 00ff 
00ff 000
ff00 ff00 000   ff00 
ff00 000
00ff 00ff 000 | 00ff 
00ff 000
ff00 ff00 000   ff00 
ff00 000
00ff 00ff 00f | 00ff 
00ff 000
ff00 ff00 ff0   ff00 
ff00 ff0
00ff 00ff 000 | 00ff 
00ff 00f
ff00 ff00 000   ff00 
ff00 000
00ff 00ff 000 | 00ff 
00ff 000

(Thanks diffoscope(1) for introducing me to the use of sng by
the way!)

With some luck, the mitigation may be as simple as applying a
swab(3) on the pixel array produced by the test, but that still
wouldn't explain why the image was completely unreadable by
image readers (it may or may not work, I still have to check).
It is also possible my approach is wrong and the problem
genuinly lies in the png converter in Orthanc.

The bug should at least remain open until the test item is back
for little endian architectures.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.3.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/8, please excuse my verbosity
   `-on air: Erik Norlander - Surreal (Feat. Lana Lane)


signature.asc
Description: PGP signature