Mamoru TASAKA wrote on 2022/02/14 17:47:
Miro Hrončok wrote on 2022/02/13 22:26:
On 13. 02. 22 13:32, Josef Řídký wrote:
Hi,

first of all, I would like to apologize for the mess I've caused by the jasper .so name 
bump in Rawhide. I entirely forgot the side-tag option and had the old mindset of having 
rawhide as a "sandbox for new features". I wrote to Miro already as I am not 
part of the proven packager group to assist me with the update - specifically with 
package rebuild.

On the other hand, I have to partially agree with Kevin Koffler in the way that 
making library upgrade in the rawhide from a regular maintainer point of view 
is still quite painful and from discussion with my colleagues it seems that I 
am not the only one who feels it that way.

Mostly, simple rebuild of dependent packages is all that is needed, but to 
achieve it, I have to either communicate with all other maintainers (where 
their number might be quite huge and not all of them are able to react in 
meningul timeframe - agree it's not applicable with handful of dependent 
packages, where it is easy to get it done) or bother some proven packager to do 
the rebuilds on my behalf (which is something I don't like, as the workload is 
transferred to someone, who has enough of his/her own tasks already).

It would be awesome to have some bot available for all Fedora maintainers, which 
would have proven packagers rights and it's only function would be -> bump spec 
file and build (e.g. in specific side-tag). In that way, for most library updates 
this would be the easiest way, how to get them into Fedora and bother other 
maintainers/proven packagers as little as possible.

Considering most of the dependent packages failed to rebuild in this case, I am 
not sure how a robot would be supposed to deal with this :(

Successful rebuilds (jasper+5):

https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=50649&order=-build_id&latest=1

Still in progress:
gdal (already succeeded on some architectures)

Failed twice (13):
LibRaw
OpenSceneGraph
digikam
eccodes
gegl04
grads
grib_api
kdelibs
kdelibs3
ncl
qt5-qtimageformats
qt6-qtimageformats
wgrib2

If somebody wants to help, build in f37-build-side-50649 please.


A
One issue as Kevin pointed out should be fixed in
https://src.fedoraproject.org/rpms/jasper/c/810e315ae32ec99e569361e680308fd14974bb20?branch=rawhide

LibRaw, gegl04, OpenSceneGraph, digikam was okay with the above change.

kdelibs3 also seems to be okay with above, but ppc64le build only failed:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82799185
Looking at build.log , it looks like parallel make issue.

B
Other issue like missing symbol on jpc_encode / jpc_decode is that now jasper 3 
hides
these internal decoder / encoder symbols:
https://github.com/jasper-software/jasper/commit/5fe57ac5829ec31396e7eaab59a688da014660af

(While I am testing now) I believe that the usage
     image=jpc_decode(jpcstream,opts);
can simply replaced with
     image=jas_image_decode (jpcstream, -1, 0);

and
     ier=jpc_encode(&image,jpcstream,opts);
can be
     fmt = jas_image_strtofmt("jpc");
     ier=jas_image_encode(&image,jpcstream,fmt,opts);

Now I am trying to fix g2clib -> grads chain dependency first.


Unfortunately eccodes testsuite now fails with the above changes
( calling jas_stream_memopen() just aborts, gdb shows like below (*))
and it seems now calling jasper function like jas_stream_memopen() now always 
have to call
some initialization functions like:

jas_conf_clear(); jas_conf_set_max_mem_usage(jas_get_total_mem_size()); 
jas_init_library(); jas_init_thread();

beforehand, and after that some shutdown functions have to be called:

jas_cleanup_thread(); jas_cleanup_library();

(and thanks to eccodes testsuite for pointing this out). With the above 
additional changes,
eccodes test suite now all passes (on x86_64, I verified only on this arch for 
now)


So simple rebuilding seems not enough and it seems all jasper consumers may 
have to
adjust internal code to jasper 3...

Is it okay for me to commit these changes? I really appreciate it if jasper 
maintainer
confirms the above changes. Or we should investigat jasper changes more 
carefully?

Regards,
Mamoru

(*) For example, one of eccodes testsuite aborts like:

Program received signal SIGABRT, Aborted.
0x00007ffff7b8cedc in __pthread_kill_implementation () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install 
glibc-2.35-2.fc37.x86_64 libgomp-12.0.1-0.7.fc37.x86_64 
libjpeg-turbo-2.1.2-2.fc36.x86_64 libpng-1.6.37-12.fc36.x86_64 
openjpeg2-2.4.0-5.fc36.x86_64 zlib-1.2.11-31.fc36.x86_64
(gdb) bt
#0  0x00007ffff7b8cedc in __pthread_kill_implementation () from /lib64/libc.so.6
#1  0x00007ffff7b3ca36 in raise () from /lib64/libc.so.6
#2  0x00007ffff7b2682f in abort () from /lib64/libc.so.6
#3  0x00007ffff7b2675b in __assert_fail_base.cold () from /lib64/libc.so.6
#4  0x00007ffff7b35596 in __assert_fail () from /lib64/libc.so.6
#5  0x00007ffff79d0209 in jas_get_ctx_internal () at 
/usr/src/debug/jasper-3.0.0-4.fc37.x86_64/src/libjasper/base/jas_init.c:919
#6  0x00007ffff79d5fdd in jas_get_ctx_internal () at 
/usr/src/debug/jasper-3.0.0-4.fc37.x86_64/src/libjasper/base/jas_init.c:919
#7  jas_get_ctx () at 
/usr/src/debug/jasper-3.0.0-4.fc37.x86_64/src/libjasper/include/jasper/jas_init.h:407
#8  jas_get_debug_level () at 
/usr/src/debug/jasper-3.0.0-4.fc37.x86_64/src/libjasper/include/jasper/jas_init.h:432
#9  jas_stream_memopen (
    buf=buf@entry=0x55555583fd80 
"\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373"...,
 bufsize=bufsize@entry=130320)
    at 
/usr/src/debug/jasper-3.0.0-4.fc37.x86_64/src/libjasper/base/jas_stream.c:208
#10 0x00007ffff7e413b9 in grib_jasper_encode (c=0x7ffff7fb0a60 
<default_grib_context>, helper=helper@entry=0x7ffffffed2b0) at 
/builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_jasper_encoding.c:175
#11 0x00007ffff7e43fda in pack_double (a=0x555555811640, cval=0x7ffff714b010, 
len=0x7ffffffed360) at 
/builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_accessor_class_data_jpeg2000_packing.c:527
#12 0x00007ffff7e8831c in _grib_set_double_array_internal (h=h@entry=0x555555813b10, 
a=a@entry=0x555555811640, val=val@entry=0x7ffff714b010, buffer_len=<optimized 
out>,
    encoded_length=encoded_length@entry=0x7ffffffed3c0, check=check@entry=0) at 
/builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_value.c:660
#13 0x00007ffff7e8844b in _grib_set_double_array (h=h@entry=0x555555813b10, 
name=name@entry=0x555555813470 "codedValues", val=val@entry=0x7ffff714b010, 
length=<optimized out>, check=check@entry=0)
    at /builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_value.c:696
#14 0x00007ffff7e88501 in grib_set_double_array_internal (h=0x555555813b10, name=0x555555813470 
"codedValues", val=0x7ffff714b010, length=<optimized out>)
    at /builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_value.c:719
#15 0x00007ffff7e3e604 in pack_double (a=0x55555581d970, val=0x7ffff714b010, 
len=0x7ffffffed4b8) at 
/builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_accessor_class_data_apply_bitmap.c:322
#16 0x00007ffff7e565d2 in grib_init_accessor_from_handle (loader=0x7ffffffed9a0, 
ga=0x55555581d970, default_value=<optimized out>) at 
/builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_loader_from_handle.c:225
#17 0x00007ffff7e0246b in create_accessor (p=0x5555558105e0, act=<optimized 
out>, h=0x7ffffffed9a0) at 
/builddir/build/BUILD/eccodes-2.24.0-Source/src/action_class_template.c:179
#18 0x00007ffff7e01b78 in notify_change (act=0x5555557fe890, notified=0x5555557fdf50, 
changed=<optimized out>) at 
/builddir/build/BUILD/eccodes-2.24.0-Source/src/action_class_section.c:177
#19 0x00007ffff7e87c78 in grib_dependency_notify_change 
(observed=observed@entry=0x5555557eafe0) at 
/builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_dependency.c:134
#20 0x00007ffff7e88018 in grib_set_long (h=<optimized out>, name=0x5555557d71a0 
"dataRepresentationTemplateNumber", val=<optimized out>) at 
/builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_value.c:111
#21 0x00007ffff7e8c9b3 in grib_set_values (h=0x555555682200, args=<optimized 
out>, count=1) at /builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_value.c:1664
#22 0x00007ffff7e111c0 in grib_concept_apply (a=<optimized out>, name=<optimized 
out>) at 
/builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_accessor_class_concept.c:415
#23 0x00007ffff7e88a1b in grib_set_string (h=<optimized out>, name=0x555555679ec0 
"packingType", val=0x555555679ee0 "grid_jpeg", length=0x7fffffffe080)
    at /builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_value.c:424
#24 0x00007ffff7e8cb20 in grib_set_values (h=h@entry=0x555555682200, 
args=args@entry=0x555555568060 <global_options+32832>, count=count@entry=1) at 
/builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_value.c:1678
#25 0x000055555555b625 in grib_tool_new_handle_action (h=0x555555682200, 
options=0x555555560020 <global_options>) at 
/builddir/build/BUILD/eccodes-2.24.0-Source/tools/grib_set.c:129
#26 0x0000555555558dfa in grib_tool_without_orderby (options=0x555555560020 
<global_options>) at 
/builddir/build/BUILD/eccodes-2.24.0-Source/tools/grib_tools.c:409
#27 grib_tool (argv=<optimized out>, argc=<optimized out>) at 
/builddir/build/BUILD/eccodes-2.24.0-Source/tools/grib_tools.c:197
#28 main (argc=<optimized out>, argv=<optimized out>) at 
/builddir/build/BUILD/eccodes-2.24.0-Source/tools/grib_set.c:60
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to