Bugzilla – Bug 1204336
Fix the availability of the symbol “rl_trim_arg_from_keyseq” (for “bash 5.2.2”)
Last modified: 2023-04-06 15:31:27 UTC
I updated some software components two days ago. I wondered about a special mixture of error messages from corresponding (slow) package download attempts. Yesterday afternoon I got surprised about a command execution failure which hindered the completion of the boot process. Thus I configured a “change root” environment by the means of the image “openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20221013-Media.iso” accordingly. But it probably points the same information out for further reconsideration of involved system dependencies. … > sudo chroot ${chr} … /bin/bash: symbol lookup error: /bin/bash: undefined symbol: rl_trim_arg_from_keyseq linux@linux:~> rpm -qi bash … Install Date: Thu 13 Oct 2022 08:40:41 PM BST … Source RPM : bash-5.2.2-1.1.src.rpm Build Date : Tue 11 Oct 2022 05:08:04 PM BST Build Host : goat05 … * How can such an implementation detail be fixed? * Do I need to switch to an other shell interpreter for a while?
(In reply to comment #0) See also: * Section “2.4.4 Associating Function Names and Bindings” https://tiswww.cwru.edu/php/chet/readline/readline.html#index-rl_005ftrim_005farg_005ffrom_005fkeyseq * readline-8.2 distribution sources and documentation https://git.savannah.gnu.org/cgit/readline.git/commit/bind.c?id=f7a382fd09319b20ef4435b9b554183b605468c1 * https://build.opensuse.org/package/show/openSUSE%3AFactory/readline
A full TW update should not only include bash 5.2 but also readline 8.2 noether:/ # echo $BASH_VERSION 5.2.2(1)-release noether:/ # nm -D /lib64/libreadline.so.8.2 | grep rl_trim_arg_from_keyseq 00000000000282f0 T rl_trim_arg_from_keyseq noether:/ # rpm -qf /lib64/libreadline.so.8.2 libreadline8-8.2-0.x86_64 if libreadline8-8.2 is missed on the TW snapshot this is also bug in the snapshot.
yast2-maintainers is the wrong maintainer ... I need the bugowner/maintainer of the TW snapshot
To fix that I could ignore the warning of rpmlint and add a hard coded dependency on libreadline8 = 8.2 ... or add all symbols of that library as the kernel does this
(In reply to Dr. Werner Fink from comment #2) > A full TW update should not only include bash 5.2 but also readline 8.2 * Are package dependency specifications really consistent for desirable software updates? * Will any adjustments become relevant for safer versioning of symbols with involved libraries according to further collateral evolution?
(In reply to Dr. Werner Fink from comment #2) … > 00000000000282f0 T rl_trim_arg_from_keyseq > noether:/ # rpm -qf /lib64/libreadline.so.8.2 > libreadline8-8.2-0.x86_64 … I got the following information while using the image “openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20221014-Media.iso” for another corresponding system analysis. linux:~ # zypper info --requires bash … Repository : openSUSE-Tumbleweed-Oss … Installed : Yes (automatically) Status : up-to-date Source package : bash-5.2.2-1.1.src … Requires : [3] libreadline.so.8()(64bit) libc.so.6(GLIBC_2.36)(64bit) libreadline.so.8(READLINE_6.3)(64bit) Thus I would appreciate if the applied package dependency specifications will be improved in more detail. https://build.opensuse.org/package/view_file/openSUSE:Factory/bash/bash.spec?expand=1 Which “RPM code” will safely trigger the inclusion of new symbols (like recently added function names)?
(In reply to Dr. Werner Fink from comment #4) Would you like to take another look at information sources like the following? * https://en.opensuse.org/openSUSE:Shared_library_packaging_policy * https://fedoraproject.org/wiki/How_to_check_for_ABI_changes_with_abidiff * https://sourceware.org/libabigail/manual/libabigail-overview.html * Article “How to write an ABI compliance checker using Libabigail” by Dodji Seketeli (from 2020-04-02) https://developers.redhat.com/blog/2020/04/02/how-to-write-an-abi-compliance-checker-using-libabigail Do you know if any analysis reports were published because of more detailed comparisons according to application binary interfaces?
Beside internal variables and functions there is one new variable, one has become an official (_rl_eof_found -> _rl_eof_found) and four new official function calls including rl_trim_arg_from_keyseq [1]. I'll try to require the explicit version of libreadline%{rl_major} for bash [1] bash/readline> abidiff /lib64/libreadline.so.8.1 /abuild/oscbuild/openSUSE_Tumbleweed/lib64/libreadline.so.8.2 Functions changes summary: 0 Removed, 0 Changed, 0 Added function Variables changes summary: 0 Removed, 0 Changed, 0 Added variable Function symbols changes summary: 0 Removed, 13 Added function symbols not referenced by debug info Variable symbols changes summary: 1 Removed, 6 Added variable symbols not referenced by debug info 13 Added function symbols not referenced by debug info: [A] _hs_at_end_of_history [A] _rl_del_executing_keyseq [A] _rl_region_color_off [A] _rl_region_color_on [A] _rl_reset_locale [A] _rl_reset_region_color [A] _rl_timeout_handle_sigalrm [A] _rl_timeout_init [A] _rl_timeout_select [A] rl_fetch_history [A] rl_set_timeout [A] rl_timeout_remaining [A] rl_trim_arg_from_keyseq 1 Removed variable symbol not referenced by debug info: [D] _rl_eof_found 6 Added variable symbols not referenced by debug info: [A] _rl_active_region_end_color [A] _rl_active_region_start_color [A] _rl_executing_func [A] _rl_history_search_pos [A] rl_eof_found [A] rl_timeout_event_hook
This is an autogenerated message for OBS integration: This bug (1204336) was mentioned in https://build.opensuse.org/request/show/1030166 Factory / bash
(In reply to Dr. Werner Fink from comment #8) > Beside internal variables and functions there is one new variable, Thanks for another constructive feedback. > one has become an official (_rl_eof_found -> _rl_eof_found) … Typo with an underscore? > I'll try to require the explicit version of libreadline%{rl_major} for bash Are the chances growing also for fixing remaining open issues according to questionable package dependency specifications?
(In reply to Markus Elfring from comment #10) > (In reply to Dr. Werner Fink from comment #8) > > Beside internal variables and functions there is one new variable, > > Thanks for another constructive feedback. > > > > one has become an official (_rl_eof_found -> _rl_eof_found) … > > Typo with an underscore? Ack ... second should be rl_eof_found > > > > I'll try to require the explicit version of libreadline%{rl_major} for bash > > Are the chances growing also for fixing remaining open issues according to > questionable package dependency specifications? Currently the new libreadline seem not to break other packages, only the bash uses the new features. It is normally not like poppler which breaks ABI rules on every release without increasing major version number.
(In reply to Dr. Werner Fink from comment #11) > > > I'll try to require the explicit version of libreadline%{rl_major} for bash > > > > Are the chances growing also for fixing remaining open issues according to > > questionable package dependency specifications? > > Currently the new libreadline seem not to break other packages, How did you check this detail? > only the bash uses the new features. Did you become more aware about corresponding consequences by this bug report? How much did you read linked information sources? > It is normally not like poppler which breaks ABI rules > on every release without increasing major version number. * Does this experience trigger further system checks for safer dependency management? * Would you like to help any more if a system configuration became broken because of inconsistent package dependency specifications? * How can a working command interpreter be achieved again for this issue?
(In reply to Markus Elfring from comment #12) > (In reply to Dr. Werner Fink from comment #11) > > > > I'll try to require the explicit version of libreadline%{rl_major} for bash > > > > > > Are the chances growing also for fixing remaining open issues according to > > > questionable package dependency specifications? > > > > Currently the new libreadline seem not to break other packages, > > How did you check this detail? All packages depending on (lib)readline will build in the OBS with the new library in case of a checkin. This is how OBS is designed. We might integrate abidiff(1), which in fact is already part of TW, within the rebuild procedure to get at least a warning. > > > only the bash uses the new features. > > Did you become more aware about corresponding consequences by this bug > report? > > How much did you read linked information sources? I did > > > It is normally not like poppler which breaks ABI rules > > on every release without increasing major version number. > > * Does this experience trigger further system checks for safer dependency > management? It had triggered many projects like several TeX engines not to use poppler anymore. This because upstream of poppler do not care about this problem. > * Would you like to help any more if a system configuration became broken > because of inconsistent package dependency specifications? One way would be not only to depend on the `magic' major version number in the libraries package name but also provide the official symbols of the libraries them self as `provides' (the kernel rpm does this) but this will increase the rpms as well as the resolving time. This would also require that packages with their binaries should require those symbols. On the other hand, e.g. the glibc package provides also version specific informations. But this is not done by (lib)readline: rpm --root /abuild/oscbuild/openSUSE_Tumbleweed/ -q --provides libreadline8 bash:/lib64/libreadline.so.8 libhistory.so.8()(64bit) libhistory.so.8(READLINE_6.3)(64bit) libreadline.so.8()(64bit) libreadline.so.8(READLINE_6.3)(64bit) libreadline8 = 8.2-38.22 libreadline8(x86-64) = 8.2-38.22 readline = 8.2 rpm -q --provides libreadline8 bash:/lib64/libreadline.so.8 libhistory.so.8()(64bit) libhistory.so.8(READLINE_6.3)(64bit) libreadline.so.8()(64bit) libreadline.so.8(READLINE_6.3)(64bit) libreadline8 = 8.1-3.9 libreadline8(x86-64) = 8.1-3.9 readline = 8.1 ... the `READLINE_6.3' is currently rather useless to detect the new features of (lib)readline-8.2. I'll investigate how get an dynamic way in the spec file to extend this, similar as done by glibc upstream. > > * How can a working command interpreter be achieved again for this issue? I do not understand this question. Do you mean to link bash static with its builtin libreadline?
(In reply to Dr. Werner Fink from comment #11) > Currently the new libreadline seem not to break other packages, > only the bash uses the new features. You might find explanations by Chet Ramey (from yesterday) interesting for topics like the following. * Checking ABI adjustments once more https://lists.gnu.org/archive/html/bug-readline/2022-10/msg00020.html * Checking evolution of information about required symbols https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00105.html
(In reply to Dr. Werner Fink from comment #13) > We might integrate abidiff(1), which in fact is already part of TW, > within the rebuild procedure to get at least a warning. I became also curious about further improvements in this software area. > > * Would you like to help any more if a system configuration became broken > > because of inconsistent package dependency specifications? > > One way would be not only to depend on the `magic' major version number in > the libraries package name but also provide the official symbols of the > libraries them self as `provides' (the kernel rpm does this) Should any more information be taken better into account according to similar dependency specification variant? > but this will increase the rpms as well as the resolving time. Did anybody measure corresponding effects in more detail? > This would also require that packages with their binaries should require those symbols. Is this approach safer than the selection of arbitrary version numbers? > On the other hand, e.g. the glibc package provides also version specific informations. Can any package specifications be extended in similar ways? > But this is not done by (lib)readline: Why not (so far)? > ... the `READLINE_6.3' is currently rather useless to detect the new features > of (lib)readline-8.2. How relevant is this version identifier at the moment? > I'll investigate how get an dynamic way in the spec file to extend this, > similar as done by glibc upstream. I am curious on further collateral evolution here. * How long were packages published which contained inappropriate dependency specifications? * Are you aware of undesirable side-effects accordingly? See also: Safer handling of extensions from the software library “readline 8.2” https://forums.opensuse.org/showthread.php/576763-Safer-handling-of-extensions-from-the-software-library-%E2%80%9Creadline-8-2%E2%80%9D > > * How can a working command interpreter be achieved again for this issue? > > I do not understand this question. I hope that a better common understanding will evolve for a questionable situation. > Do you mean to link bash static with its builtin libreadline? * A statically linked executable file variant can occasionally be useful. But under which circumstances can it actually be used? * If shared libraries can be properly installed according to required symbols, the situation should usually look also more promising. * Would you get into the mood to choose an other command interpreter for the shell to fulfil any advanced constraints?
This is an autogenerated message for OBS integration: This bug (1204336) was mentioned in https://build.opensuse.org/request/show/1030327 Factory / readline
With the accepted SR#1030327 at least the proble mshould be resolved for the next snapshot od the Tumbleweed
(In reply to Dr. Werner Fink from comment #17) I got the impression that this issue was not completely fixed so far. I am still looking for advice and further solution ideas according to information which I pointed out additionally.
(In reply to Markus Elfring from comment #18) > (In reply to Dr. Werner Fink from comment #17) > I got the impression that this issue was not completely fixed so far. > I am still looking for advice and further solution ideas according to > information which I pointed out additionally. With the version script for the linker the symbol rl_trim_arg_from_keyseq triggers the symbol libreadline.so.8(READLINE_8.2)(64bit) which in fact is also required by the bash now. What is still missed here?
(In reply to Dr. Werner Fink from comment #19) > What is still missed here? Are you aware of damages which happened before package dependency specifications were improved? How do you think about to help with fixing remaining open issues according to questionable status of any software components?
(In reply to Markus Elfring from comment #20) > (In reply to Dr. Werner Fink from comment #19) > > What is still missed here? > > Are you aware of damages which happened before package dependency > specifications were improved? > > How do you think about to help with fixing remaining open issues according > to questionable status of any software components? You might clone this bug for a more general feature request. That is an implementation of a better detection of such problems. Maybe with an further build/rpmlint check for new of different symbols by the same major number for the soname of a shared library.
(In reply to Dr. Werner Fink from comment #21) > (In reply to Markus Elfring from comment #20) > > (In reply to Dr. Werner Fink from comment #19) > > > What is still missed here? > > > > Are you aware of damages which happened before package dependency > > specifications were improved? Does anything hinder you to provide a concrete answer for this repeated question? > > How do you think about to help with fixing remaining open issues according > > to questionable status of any software components? > > You might clone this bug for a more general feature request. Further collateral evolution will become more interesting, won't it? > That is an implementation of a better detection of such problems. I became especially curious on corresponding possibilities for repairs of (my) affected development systems. > Maybe with an further build/rpmlint check for new of different symbols by the same major number > for the soname of a shared library. Can any search patterns be determined for such use cases?
I've no idea what you want from me. You have reported a problem/bug against bash/readline and this problem is (IMHO) solved. As package maintainer I've no influence on any other (aka not package related) solutions.
(In reply to Dr. Werner Fink from comment #24) > I've no idea what you want from me. I find that this view will need further clarification for possible contributions. > You have reported a problem/bug against bash/readline Yes. > and this problem is (IMHO) solved. This view depends on the time direction. Future: Probably, yes. Historical side-effects: Not yet. > As package maintainer I've no influence on any other (aka not package related) solutions. Would you like to take more possibilities into account for repairing software components by the means of considerably improved package? Will the experiences grow for known damages from recent issues?
(In reply to Markus Elfring from comment #25) > Would you like to take more possibilities into account for repairing > software components by the means of considerably improved package? > > Will the experiences grow for known damages from recent issues? I can not repair TW snapshots. What can be done is to boot a rescue system, e.g. from a boot image (DVD, USB), mount the root file system rw on a mount point like /mnt, and then install the correct libreadline8 or derease bash and libreadline8 version below /mnt
(In reply to Dr. Werner Fink from comment #26) > (In reply to Markus Elfring from comment #25) > > Would you like to take more possibilities into account for repairing > > software components by the means of considerably improved package? > > > > Will the experiences grow for known damages from recent issues? > > I can not repair TW snapshots. I find that this view can also be reconsidered. I imagine that you have got some influence on the evolution which will trigger the generation of further openSUSE Tumbleweed snapshots (so that improvements will be provided accordingly). > What can be done is to boot a rescue system, I am temporarily working again with some Live systems (which were published as ISO images). > e.g. from a boot image (DVD, USB), mount the root file system rw on a mount > point like /mnt, and then install the correct libreadline8 or derease bash > and libreadline8 version below /mnt Can any of such actions be achieved by software packages with repair capabilities? Can any tools (from the “outside”) achieve that a corresponding “chroot” environment will become usable again for further package management in such a system configuration?
(In reply to Markus Elfring from comment #27) > (In reply to Dr. Werner Fink from comment #26) > > (In reply to Markus Elfring from comment #25) > > > Would you like to take more possibilities into account for repairing > > > software components by the means of considerably improved package? > > > > > > Will the experiences grow for known damages from recent issues? > > > > I can not repair TW snapshots. > > I find that this view can also be reconsidered. The snapshot should be removed (IMHO). > > I imagine that you have got some influence on the evolution which will > trigger the generation of further openSUSE Tumbleweed snapshots (so that > improvements will be provided accordingly). Which exactly had happen with the accepted submit request 1030327 > > > > What can be done is to boot a rescue system, > > I am temporarily working again with some Live systems (which were published > as ISO images). > > > e.g. from a boot image (DVD, USB), mount the root file system rw on a mount > > point like /mnt, and then install the correct libreadline8 or derease bash > > and libreadline8 version below /mnt > > Can any of such actions be achieved by software packages with repair > capabilities? Nope, that is the job of the system administrator > Can any tools (from the “outside”) achieve that a corresponding “chroot” > environment will become usable again for further package management in such > a system configuration? The steps done by the system administrator could be done within a shell script
(In reply to OBSbugzilla Bot from comment #9) … > https://build.opensuse.org/request/show/1030166 Factory / bash (In reply to OBSbugzilla Bot from comment #16) … > https://build.opensuse.org/request/show/1030327 Factory / readline A corresponding announcement was published: 2022-10-24 New Tumbleweed snapshot 20221023 released! https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/XZ3S5XI6A7CWX6EK3MXUM2KNHC2N7W6U/
(In reply to Dr. Werner Fink from comment #28) > > Can any of such actions be achieved by software packages with repair capabilities? > > Nope, that is the job of the system administrator I dare to present an other view for more desirable software evolution. > > Can any tools (from the “outside”) achieve that a corresponding “chroot” > > environment will become usable again for further package management in such > > a system configuration? > > The steps done by the system administrator could be done within a shell script This “administrator” is occasionally just me. Thus I am trying also to reduce known obstacles.
Examples for open issues for which it would also be nice to find appropriate solutions: * 2022-10-19 https://github.com/ventoy/Ventoy/issues/1924 Technical details hinder the collaboration of the software “Ventoy 1.0.80” with images like “openSUSE-Tumbleweed-{GNOME,KDE,XFCE}-Live-x86_64-Snapshot20221023-Media.iso”. * 2022-10-17 https://bugzilla.opensuse.org/show_bug.cgi?id=1204360 Fix determination for canonical path of “/boot/grub2” (by a distribution upgrade)
(In reply to Dr. Werner Fink from comment #28) > Which exactly had happen with the accepted submit request 1030327 I got the following information from the execution environment based on the image “openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20221024-Media.iso”. linux:~ # zypper info --requires bash … Repository : openSUSE-Tumbleweed-Oss … Installed : Yes (automatically) Status : up-to-date Source package : bash-5.2.2-3.1.src … Requires : [7] libreadline.so.8()(64bit) libc.so.6(GLIBC_2.36)(64bit) libreadline.so.8(READLINE_6.3)(64bit) libreadline.so.8(READLINE_7.0)(64bit) libreadline.so.8(READLINE_8.0)(64bit) libreadline.so.8(READLINE_8.2)(64bit) libreadline8 = 8.2 * Should the package requirement specifications be excluded for outdated versions of the corresponding library? * Will the dependencies be properly adjusted for future revisions?
(In reply to Dr. Werner Fink from comment #13) > Do you mean to link bash static with its builtin libreadline? I constructed such a build configuration within an execution environment based on the image “openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20221025-Media.iso”. linux@linux:…/Projekte/Bau/bash/static> file bash bash: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=2db71dea17e91f85b9825a2f356c504b7925b3e1, for GNU/Linux 3.2.0, with debug_info, not stripped linux@linux:…/Projekte/Bau/bash/static> ./bash --version GNU bash, Version 5.2.2(2)-release (x86_64-pc-linux-gnu) … I could activate a “chroot” environment then. … bash-5.2# zypper up libreadline8 readline-doc Loading repository data... Reading installed packages... Resolving package dependencies... The following 2 packages are going to be upgraded: libreadline8 readline-doc 2 packages to upgrade. Overall download size: 424.1 KiB. Already cached: 0 B. After the operation, additional 53.4 KiB will be used. Continue? [y/n/v/...? shows all options] (y): … (1/2) Installing: readline-doc-8.2-2.1.noarch ...................................................................................[done] … (2/2) Installing: libreadline8-8.2-2.1.x86_64 ...................................................................................[done] bash-5.2# zypper lu|grep system zypper: symbol lookup error: /usr/local/lib64/libreadline.so.8: undefined symbol: UP Another error message indicates software development challenges for further considerations. Which step should be picked for the next repair approach?
There seems not really a bug left to be fixed. The packages are consistent with each other (never do update single packages on TW, always use zypper dup) Using a live/Rescue system one can install missing/corrupt packages into the disk root once such a corrupt state arises