Bug 2421762 - rubygem-image_processing: FTBFS in Fedora Rawhide
Summary: rubygem-image_processing: FTBFS in Fedora Rawhide
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: vips
Version: rawhide
Hardware: s390x
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Adam Goode
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-12-12 15:28 UTC by Mamoru TASAKA
Modified: 2025-12-19 15:56 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)
Test input image (133.04 KB, image/jpeg)
2025-12-19 15:47 UTC, Mamoru TASAKA
no flags Details

Description Mamoru TASAKA 2025-12-12 15:28:06 UTC
Description of problem:
Package rubygem-image_processing fails to build from source in Fedora Rawhide.

Version-Release number of selected component (if applicable):
1.14.0-2.fc44

Steps to Reproduce:
koji build --scratch --arch-override=i686,x86_64,aarch64,ppc64le,s390x f44 rubygem-image_processing-1.14.0-2.fc44.src.rpm

Note: rubygem-image_processing itself is noarch, so by default only one arch is chosen when rebuilding. To try building on specific arch, explicitly passing "--arch-override=" option is needed (or use copr)

Results: build fails on s390x:
https://koji.fedoraproject.org/koji/taskinfo?taskID=139940415

```
# Running:
..S...........S......SS.....F.S...S...........S....SSSS.F..........S..SS.SSF.S.S..........S.F.......S..F.S.............S.S..SSSS......S...S....S...S.....SS............S.S.SSSSS.S
Finished in 9.490585s, 18.7554 runs/s, 26.0258 assertions/s.
  1) Failure:
ImageProcessing::Vips::#resize_to_fit#test_0007_accepts sharpening options [test/vips_test.rb:228]:
Expected sharpened thumbnail to have bigger filesize than not sharpened thumbnail
  2) Failure:
ImageProcessing::Vips::#resize_to_fill#test_0005_accepts sharpening options [test/vips_test.rb:264]:
Expected sharpened thumbnail to have bigger filesize than not sharpened thumbnail
  3) Failure:
ImageProcessing::Vips::#resize_and_pad#test_0007_accepts sharpening options [test/vips_test.rb:318]:
Expected sharpened thumbnail to have bigger filesize than not sharpened thumbnail
  4) Failure:
ImageProcessing::Vips::#resize_to_cover#test_0012_accepts sharpening options [test/vips_test.rb:385]:
Expected sharpened thumbnail to have bigger filesize than not sharpened thumbnail
  5) Failure:
ImageProcessing::Vips::#resize_to_limit#test_0007_accepts sharpening options [test/vips_test.rb:180]:
Expected sharpened thumbnail to have bigger filesize than not sharpened thumbnail
178 runs, 247 assertions, 5 failures, 0 errors, 41 skips
```


Additional info:
* With vips-8.17.3-1.fc44.s390x (from koji), testsuite for rubygem-image_processing fails.
* With vips-8.17.1-3.fc44.s390x (from koji) testsuite for rubygem-image_processing succeeds.

So firstly it looked like there was some regression between vips 8.17.1 and 8.17.3.
But:

* With rebuilding vips-8.17.1-3.fc44 now (using koji) targeting for f44 buildroot, and using it, then testsuite for rubygem-image_processing now fails(??)
* Using vips-8.17.1 rebuilt for f43 buildroot now, testsuite again fails

Now currently I don't know well where to investigate further...

Comment 2 Mamoru TASAKA 2025-12-19 15:51:11 UTC
ruby test case:
https://github.com/janko/image_processing/blob/8185ea61518d8cf477594505cd4b5ab478b28aea/test/vips_test.rb#L177-L181

And in C:
resize-to-limit-test.c

```
#include <stdlib.h>
#include <stdio.h>
#include <glib.h>
#include <vips/vips.h>
#include <sys/stat.h>

#define MY_ASSERT(expr) \
do { \
	if (!(expr)) { \
		fprintf(stderr, "LINE[%d] : assertion \"" #expr "\" failed.\n", __LINE__); \
		abort(); \
	} \
} while(0)


int main(void) {
	VipsImage *normal_image, *sharpened_image, *tmp_image;
	VipsImage *sharpen_mask_image;
	int ret;

#define MASK_WIDTH  (3)
#define MASK_HEIGHT (3)
#define MASK_DIMENSION (MASK_WIDTH * MASK_HEIGHT)

	static const int sharpen_array_2d_int[MASK_WIDTH][MASK_HEIGHT] = {
		{-1, -1, -1,},
		{-1, 32, -1,},
		{-1, -1, -1},
	};
	static double sharpen_array_1d_double[MASK_DIMENSION];
	const char *input_path = "./portrait.jpg";

	ret = vips_thumbnail(
			input_path, &normal_image,
			400,
			"height", 400,
			"size", VIPS_SIZE_DOWN,
			NULL
		);
	MY_ASSERT(!ret);
	ret = vips_thumbnail(
			input_path, &tmp_image,
			400,
			"height", 400,
			"size", VIPS_SIZE_DOWN,
			NULL
		);
	MY_ASSERT(!ret);

	for (int count = 0; count < MASK_DIMENSION; count++) {
		sharpen_array_1d_double[count] = (double)(((const int *)sharpen_array_2d_int)[count]);
	}
	sharpen_mask_image = 
		vips_image_new_matrix_from_array(
			MASK_WIDTH, MASK_HEIGHT, sharpen_array_1d_double, MASK_DIMENSION
			);
	MY_ASSERT(sharpen_mask_image);

	{
		GValue value = G_VALUE_INIT;

		g_value_init(&value, G_TYPE_DOUBLE);
		g_value_set_double(&value, 24);
		vips_image_set(sharpen_mask_image, "scale", &value);
		g_value_unset(&value);
	}
	{
		GValue value = G_VALUE_INIT;

		g_value_init(&value, G_TYPE_DOUBLE);
		g_value_set_double(&value, 0);
		vips_image_set(sharpen_mask_image, "offset", &value);
		g_value_unset(&value);
	}

	ret = vips_conv(
			tmp_image, &sharpened_image,
			sharpen_mask_image,
			"precision", VIPS_PRECISION_INTEGER,
			NULL
		);
	MY_ASSERT(!ret);

	vips_image_write_to_file(normal_image, "normal.jpg", NULL);
	vips_image_write_to_file(sharpened_image, "sharpened.jpg", NULL);

	struct stat st_normal, st_sharpened;
	int size_normal, size_sharpened;

	stat("./normal.jpg", &st_normal);
	stat("./sharpened.jpg", &st_sharpened);
	size_normal = (int)st_normal.st_size;
	size_sharpened = (int)st_sharpened.st_size;

	/* On x86_64, this is "26544 28915" */
	fprintf(stdout, "%d %d\n", size_normal, size_sharpened);
	MY_ASSERT(size_sharpened > size_normal);

}
```

```
$ gcc $(rpm --eval %optflags) $(pkg-config --cflags --libs vips glib-2.0) -o resize-to-limit-test{,.c}  && ./resize-to-limit-test
```
reproduces this issue.

So C only side reproduce this. Switching to vips.

Comment 3 Mamoru TASAKA 2025-12-19 15:56:49 UTC
And in fact on s390x, the generated "normal.jpg" and "sharpened.jpg" are both "meaningless" images.

Reported: https://github.com/libvips/libvips/issues/4815
Workaround seems to be setting "env VIPS_NOVECTOR=1" .


Note You need to log in before you can comment on or make changes to this bug.