Re: Unannounced soname bump: libjasper.so.4 -> libjasper.so.6

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux