Bugzilla – Bug 1054448
ncurses rendering is broken in xterm
Last modified: 2021-07-10 00:33:42 UTC
Created attachment 737266 [details] y2log Launching yast in xterm results in broken rendering of UI elements. Curiously, if environment variable TERM is set to something other than xterm, yast will render properly.
I found out that the problem is caused by updated terminfo-base package, when I copy the /usr/share/terminfo/x/xterm from openSUSE 42.2 then it works correctly. (I guess 42.3 or SLES12-SP3 should work as well.) The workaround is to run yast with TERM=linux (or something else, depending on the terminal used), in an SSH installation use "TERM=linux yast.ssh" command for starting the installer. Changing the component to Basesystem as the problem seems to in the /usr/share/terminfo/x/xterm file in terminfo-base package (ncurses source RPM).
*** Bug 1054998 has been marked as a duplicate of this bug. ***
*** Bug 1055092 has been marked as a duplicate of this bug. ***
*** Bug 1055281 has been marked as a duplicate of this bug. ***
*** Bug 1055642 has been marked as a duplicate of this bug. ***
*** Bug 1054459 has been marked as a duplicate of this bug. ***
Same problem on SLE 15 s390x (bsc#1054459 was recorded as duplicate of this bug). ## Observation openQA test in scenario sle-15-Leanos-DVD-s390x-textmode@s390x-zVM-vswitch-l3 shows broken characters in [welcome](https://openqa.suse.de/tests/1119106/modules/welcome/steps/2) ## Reproducible Fails reproducibly, check latest link ## Expected result Last good: [SLE 12 SP3](https://openqa.suse.de/tests/1058168#step/welcome/1) ## Further details Always latest result in this scenario: [latest](https://openqa.suse.de/tests/latest?distri=sle&test=textmode&arch=s390x&version=15&machine=s390x-zVM-vswitch-l3&flavor=Leanos-DVD)
*** Bug 1054681 has been marked as a duplicate of this bug. ***
*** Bug 1056698 has been marked as a duplicate of this bug. ***
*** Bug 1054894 has been marked as a duplicate of this bug. ***
(In reply to Ladislav Slezák from comment #1) > I found out that the problem is caused by updated terminfo-base package, > when I copy the /usr/share/terminfo/x/xterm from openSUSE 42.2 then it works > correctly. > (I guess 42.3 or SLES12-SP3 should work as well.) > > The workaround is to run yast with TERM=linux (or something else, depending > on the terminal used), in an SSH installation use "TERM=linux yast.ssh" > command for starting the installer. > > > Changing the component to Basesystem as the problem seems to in the > /usr/share/terminfo/x/xterm file in terminfo-base package (ncurses source > RPM). Thank you Ladislav. The term "xterm-color" works correctly too. Put alias for sudo and yast in "~/.alias" or "~/.bashrc" file: alias sudo='sudo ' alias yast='TERM=xterm-color yast'
*** Bug 1054509 has been marked as a duplicate of this bug. ***
*** Bug 1057584 has been marked as a duplicate of this bug. ***
For all reporters: Does this bug happen in an XTerm ... no gnome-, no xfce4-, no konsole, no other then XTerm terminal?
(In reply to Dr. Werner Fink from comment #14) > For all reporters: > > Does this bug happen in an XTerm ... no gnome-, no xfce4-, no konsole, > no other then XTerm terminal? I saw it in GNOME terminal (bug 1055642).
clearing needinfo
(In reply to Martin Wilck from comment #15) > (In reply to Dr. Werner Fink from comment #14) > > For all reporters: > > > > Does this bug happen in an XTerm ... no gnome-, no xfce4-, no konsole, > > no other then XTerm terminal? > > I saw it in GNOME terminal (bug 1055642). This was not the question: Does this happen in XTerm? (In reply to Martin Wilck from comment #16) > clearing needinfo Please be aware that TERM=xterm describes the XTerm and not the gnome-terminal.
I can confirm it happens for Xterm in Gnome after I've just updated my TW and rebooted.
Just build latest ncurses 6.0-20170909 from Base:System/ncurses from OBS and at least htop works perfect. Please for every reporter check out http://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/x86_64/libncurses6-6.0-416.2.x86_64.rpm http://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/x86_64/terminfo-base-6.0-416.2.x86_64.rpm that is the libraries as well as the terminfo base. Afdter installing both packages please test out your use case within an real(!) XTerm
(In reply to Dr. Werner Fink from comment #19) > Just build latest ncurses 6.0-20170909 from Base:System/ncurses from OBS and > at least htop works perfect. > > Please for every reporter check out > > http://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/ > x86_64/libncurses6-6.0-416.2.x86_64.rpm > http://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/ > x86_64/terminfo-base-6.0-416.2.x86_64.rpm > > that is the libraries as well as the terminfo base. Afdter installing both > packages please test out your use case within an real(!) XTerm Just tested and I can verify all works (XTerm: htop, yast2, gdb) and all these also in gnome-terminal. Thanks, good job.
(In reply to Martin Liška from comment #20) > Just tested and I can verify all works (XTerm: htop, yast2, gdb) and all > these also in gnome-terminal. Thanks, good job. Thanks for this feedback!
Fixed for me too. Thanks !
*** Bug 1058244 has been marked as a duplicate of this bug. ***
*** Bug 1058246 has been marked as a duplicate of this bug. ***
also openQA tests are fine now: https://openqa.suse.de/tests/1166353#step/welcome/3
*** Bug 1058660 has been marked as a duplicate of this bug. ***
Have to reopen. The verification link I provided was about the installation which I originally reported in another bug which has been closed as a duplicate. The problem is fixed there but not when calling yast2 from within either xterm or gnome-terminal. Reproduced on SLES build 260.4. Confirmed working workaround by calling `TERM=xterm-color yast2`.
(In reply to Oliver Kurz from comment #27) > Have to reopen. The verification link I provided was about the installation > which I originally reported in another bug which has been closed as a > duplicate. The problem is fixed there but not when calling yast2 from within > either xterm or gnome-terminal. Reproduced on SLES build 260.4. Confirmed > working workaround by calling `TERM=xterm-color yast2`. And which ncurses version does this SLES build 260.4 include now? Also I'd like to see a screen shot to be clear what we are talking about.
Created attachment 741109 [details] screenshot of yast ncurses UI within SLES 15 build 260.4 zypper search --details --installed-only ncurses S | Name | Type | Version | Arch | Repository --+---------------------+---------+------------+--------+-------------------------------- i | libncurses6 | package | 6.0-3.6 | x86_64 | SLE-Module-Basesystem15-Pool i | libyui-ncurses-pkg8 | package | 2.48.5-1.2 | x86_64 | SLE-Module-Basesystem15-Pool i | libyui-ncurses8 | package | 2.48.4-1.2 | x86_64 | SLE-Module-Basesystem15-Pool i | ncurses-utils | package | 6.0-3.6 | x86_64 | SLE-Module-Basesystem15-Pool
(In reply to Oliver Kurz from comment #29) > Created attachment 741109 [details] > screenshot of yast ncurses UI within SLES 15 build 260.4 > > zypper search --details --installed-only ncurses > S | Name | Type | Version | Arch | Repository > > --+---------------------+---------+------------+--------+-------------------- > ------------ > i | libncurses6 | package | 6.0-3.6 | x86_64 | > SLE-Module-Basesystem15-Pool > i | libyui-ncurses-pkg8 | package | 2.48.5-1.2 | x86_64 | > SLE-Module-Basesystem15-Pool > i | libyui-ncurses8 | package | 2.48.4-1.2 | x86_64 | > SLE-Module-Basesystem15-Pool > i | ncurses-utils | package | 6.0-3.6 | x86_64 | > SLE-Module-Basesystem15-Pool Useless ... please do rpm -q --changelog libncurses6 | head -n 20 beside this: IS this the latest YaST2 ncurses GUI package? Compare with changelog Tue Jul 4 07:58:10 UTC 2017 - mfilka@suse.com - bnc#1047145 - patch to make the package buildable by gcc7 (by werner@suse.com) - 2.48.3 Tue May 9 14:11:59 CEST 2017 - snwint@suse.de - adjustments needed to work with latest ncurses update (bsc#1034922) - 2.48.2 Also provide a character image with the help of tee.
Btw: does any other curses based application show problems? The new feature added in ncurses-6.0-20170729 is + add "rep" to xterm-new, available since 1997/01/26 -TD maybe YaST2 ncurses GUI can not handle this ... from man 5 terminfo Variable Cap- TCap Description Numeric name Code [...] repeat_char rep rp repeat char #1 #2 times (P*) if so this is not a bug of ncurses ... and from the pictures it looks like repeating of an ANSI line graphic characters are not repeated well or the smacs/rmacs switch is missed for repeating line graphic characters.
> Please for every reporter check out > > http://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/ > x86_64/libncurses6-6.0-416.2.x86_64.rpm > http://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/ > x86_64/terminfo-base-6.0-416.2.x86_64.rpm > > that is the libraries as well as the terminfo base. Afdter installing both > packages please test out your use case within an real(!) XTerm When will it make it to Tumbleweed? Or at least how to check the status? Because currently it is still broken and I wonder if it is expected.
Got some feedback from upstream, compare with https://lists.gnu.org/archive/html/bug-ncurses/2017-09/msg00013.html that is that the rep (repeate_character) works only for ascii line drawings and only if the ASCII code of the line drawing character is used tput -S <<! smacs rep 45 20 rmacs ! works where as `-' for ASCII character 45 does not tput -S <<! smacs rep - 20 rmacs !
Now to draw a line I've tried ACS_S3 which is ASCII `-' and VT100 `p' aka character 112 which indeed tput -S <<! smacs rep 112 20 rmacs ! provides a perfect line whereas tput -S <<! smacs rep p 20 rmacs ! leads to �
All four line glpyhs do work tput -S <<! smacs rep 112 20 rmacs ! ⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻ tput -S <<! smacs rep 113 20 rmacs ! ──────────────────── tput -S <<! smacs rep 114 20 rmacs ! ⎼⎼⎼⎼⎼⎼⎼⎼⎼⎼⎼⎼⎼⎼⎼⎼⎼⎼⎼⎼ tput -S <<! smacs rep 115 20 rmacs ! ⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽
Adding YaST team to carbon copy as it might be necessary to change libyui-ncurses at the point of using repeate character feature
Created attachment 741205 [details] shell script rep.tst Call this in an XTerm or XTerm compatible terminal emulator with TERM=xterm with latest ncurses installed by bash rep.tst and you should see ┌────────────────────┐ │ │ │ │ │ │ └────────────────────┘ latest ncurses means: infocmp -T xterm -1 | grep rep= rep=%p1%c\E[%p2%{1}%-%db,
Beside the ncurses GUI of YaST2 ... which ncurses based applications around here do have similar problems with latest ncurses proclaiming the XTerm feature of repeating characters in the terminfo entry xterm?
*** Bug 1059301 has been marked as a duplicate of this bug. ***
(In reply to Dr. Werner Fink from comment #42) > Beside the ncurses GUI of YaST2 ... which ncurses based applications around > here do have similar problems with latest ncurses proclaiming the XTerm > feature of repeating characters in the terminfo entry xterm? ncdu, for instance, is having the same problem.
(In reply to Imobach Gonzalez Sosa from comment #44) > (In reply to Dr. Werner Fink from comment #42) > > Beside the ncurses GUI of YaST2 ... which ncurses based applications around > > here do have similar problems with latest ncurses proclaiming the XTerm > > feature of repeating characters in the terminfo entry xterm? > > ncdu, for instance, is having the same problem. Thanks for feedback! Do you have a screen shot around ... the source code of ncdu seems to be very simple on drawing lines, therefore I'd like to see where on the screen the repeating character feature is misinterpreted and which function this is (e.g. ncurses or ncdu ... or both)
(In reply to Dr. Werner Fink from comment #30) > Useless ... please do > > rpm -q --changelog libncurses6 | head -n 20 # rpm -q --changelog libncurses6 | head -n 20 * Mon Jul 31 2017 werner@suse.de - Add ncurses patch 20170729 > Also provide a character image with the help of tee. I don't understand what I should do here. I tried 'yast2 2>&1 | tee 2>&1' to no avail - if that would be any useful. (In reply to Dr. Werner Fink from comment #42) > Beside the ncurses GUI of YaST2 ... which ncurses based applications around > here do have similar problems with latest ncurses proclaiming the XTerm > feature of repeating characters in the terminfo entry xterm? Something as simple as `dialog --yesno "foo" 3 20` also looks broken on SLES15 build 260.4 so very simple to reproduce I assume.
(In reply to Oliver Kurz from comment #46) > I don't understand what I should do here. I tried 'yast2 2>&1 | tee 2>&1' to > no avail - if that would be any useful. Then YaST write to its own file descriptor ... nevertheless in principle it is possible to a) repeat simply by `cat character.trace > /dev/tty' the result and b) simply read the file with an binary editor or viewer or even with od -t o1
Created attachment 741365 [details] dialog.png with ncurses 6.0-20170916 (In reply to Oliver Kurz from comment #46) > > Something as simple as `dialog --yesno "foo" 3 20` also looks broken on > SLES15 build 260.4 so very simple to reproduce I assume. Here I've ncurses 6.0-20170916 with # infocmp -T xterm -1 | grep rep= # rep=%p1%c\E[%p2%{1}%-%db, within an real XTerm (xterm 308) ... I'll try yast2 ncurses as next
Created attachment 741366 [details] ncdu.png with ncurses 6.0-20170916 and TERM=xterm with rep feature
Created attachment 741367 [details] yast-nui.png with ncurses 6.0-20170916 and TERM=xterm with rep feature
Please retest with at leat ncurses 6.0-20170916
(In reply to Dr. Werner Fink from comment #51) > Please retest with at least ncurses 6.0-20170916 Do you have any repo I could add to test this newer version? Just for the record; I've updated my TW today with the following versions and is still broken: S | Name | Type | Version | Arch | Repository --+---------------------+---------+------------+--------+---------------------- i | libncurses6 | package | 6.0-27.2 | x86_64 | Main Repository (OSS) i | libncurses6 | package | 6.0-27.2 | x86_64 | openSUSE-20170304-0 i | libncurses6-32bit | package | 6.0-27.2 | x86_64 | Main Repository (OSS) i | libncurses6-32bit | package | 6.0-27.2 | x86_64 | openSUSE-20170304-0 i | libyui-ncurses-pkg8 | package | 2.48.5-1.1 | x86_64 | Main Repository (OSS) i | libyui-ncurses-pkg8 | package | 2.48.5-1.1 | x86_64 | openSUSE-20170304-0 i | libyui-ncurses8 | package | 2.48.4-1.1 | x86_64 | Main Repository (OSS) i | libyui-ncurses8 | package | 2.48.4-1.1 | x86_64 | openSUSE-20170304-0 i | ncurses-devel | package | 6.0-27.2 | x86_64 | Main Repository (OSS) i | ncurses-devel | package | 6.0-27.2 | x86_64 | openSUSE-20170304-0 i | ncurses-utils | package | 6.0-27.2 | x86_64 | Main Repository (OSS) i | ncurses-utils | package | 6.0-27.2 | x86_64 | openSUSE-20170304-0
(In reply to Nick Singer from comment #52) > (In reply to Dr. Werner Fink from comment #51) > > Please retest with at least ncurses 6.0-20170916 > > Do you have any repo I could add to test this newer version? > > > Just for the record; I've updated my TW today with the following versions > and is still broken: > https://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/ or with osc osc ls -b Base:System ncurses openSUSE_Factory/x86_64 ::import::i586::libncurses5-32bit-6.0-421.1.x86_64.rpm ::import::i586::libncurses5-32bit-debuginfo-6.0-421.1.x86_64.rpm ::import::i586::libncurses6-32bit-6.0-421.1.x86_64.rpm ::import::i586::libncurses6-32bit-debuginfo-6.0-421.1.x86_64.rpm ::import::i586::ncurses-devel-32bit-6.0-421.1.x86_64.rpm ::import::i586::ncurses-devel-32bit-debuginfo-6.0-421.1.x86_64.rpm _buildenv _statistics libncurses5-6.0-421.1.x86_64.rpm libncurses5-debuginfo-6.0-421.1.x86_64.rpm libncurses6-6.0-421.1.x86_64.rpm libncurses6-debuginfo-6.0-421.1.x86_64.rpm ncurses-6.0-421.1.src.rpm ncurses-debuginfo-6.0-421.1.x86_64.rpm ncurses-debugsource-6.0-421.1.x86_64.rpm ncurses-devel-6.0-421.1.x86_64.rpm ncurses-devel-debuginfo-6.0-421.1.x86_64.rpm ncurses-utils-6.0-421.1.x86_64.rpm ncurses-utils-debuginfo-6.0-421.1.x86_64.rpm ncurses5-devel-6.0-421.1.x86_64.rpm rpmlint.log tack-6.0-421.1.x86_64.rpm tack-debuginfo-6.0-421.1.x86_64.rpm terminfo-6.0-421.1.x86_64.rpm terminfo-base-6.0-421.1.x86_64.rpm terminfo-iterm-6.0-421.1.x86_64.rpm terminfo-screen-6.0-421.1.x86_64.rpm
For reports please specify the first few lines of the changelog of the packages terminfo, terminfo-base, and libncurses6 ... if identical only once ... also report the terminal emulator which is used with TERM=xterm.
(In reply to Dr. Werner Fink from comment #53) > (In reply to Nick Singer from comment #52) > > (In reply to Dr. Werner Fink from comment #51) > > > Please retest with at least ncurses 6.0-20170916 > > > > Do you have any repo I could add to test this newer version? > > > > > > Just for the record; I've updated my TW today with the following versions > > and is still broken: > > > > https://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/ Thanks. I've added this repo and force-installed libncurses6 again. This resulted only in a vendor-change for libncurses6 and ncurses-devel (expected). Now ncurses applications (weechat, tmux, htop, ncmpcpp and ncdu tested) seem to work fine again with rxvt-unicode as terminal emulator and TERM=xterm-256color. I've not tested other terminal emulators / TERM-variables yet.
(In reply to Nick Singer from comment #55) > Thanks. I've added this repo and force-installed libncurses6 again. This > resulted only in a vendor-change for libncurses6 and ncurses-devel > (expected). > Now ncurses applications (weechat, tmux, htop, ncmpcpp and ncdu tested) seem > to work fine again with rxvt-unicode as terminal emulator and > TERM=xterm-256color. I've not tested other terminal emulators / > TERM-variables yet. Seems to be sufficient: infocmp -T xterm-256color -1 | grep rep= rep=%p1%c\E[%p2%{1}%-%db,
https://openqa.suse.de/tests/1181415/modules/welcome/steps/1 shows a problem in the installer of SLE15 build 274.1 over a IPMI remote control interface. https://openqa.suse.de/tests/1179378#step/welcome/1 is a reference of SLE12SP2 displayed correctly. Without an updated installer image or at least a DUD for the installation medium I don't think I can be of much help to fix these issues. Of course, when someone supplies me a SLE repo with updated ncurses I can try to fix the issue we already saw in xterm/gnome-terminal. I recommend to regard this ticket with high priority regarding to SLE15 development.
(In reply to Oliver Kurz from comment #57) > https://openqa.suse.de/tests/1181415/modules/welcome/steps/1 shows a problem > in the installer of SLE15 build 274.1 over a IPMI remote control interface. > https://openqa.suse.de/tests/1179378#step/welcome/1 is a reference of > SLE12SP2 displayed correctly. Without an updated installer image or at least > a DUD for the installation medium I don't think I can be of much help to fix > these issues. Of course, when someone supplies me a SLE repo with updated > ncurses I can try to fix the issue we already saw in xterm/gnome-terminal. I > recommend to regard this ticket with high priority regarding to SLE15 > development. Hmm ... and what exactly can I do here? Maybe it is a better idea to asign this bug to someone which has the decision control about Tumbleweed as well as about SLES15 as otherwise nothing will happen
Note that the temrinal emulators claiming to be XTerm compatible have to be fixed to be able to support the 'rep'eat character feature of the XTerm (since 1997). https://bugs.kde.org/show_bug.cgi?id=384620 https://bugzilla.gnome.org/show_bug.cgi?id=787701
Questions:a) whern will the ncurses version from Base:System reach Tumbleweed and b) whern will this happen for SLES-15, and at least but not least c) should I disable the declaration of the "rep" feature (repeat character up to the point where all broken terminal emluators (compare bug#1056020) become fixed e.g. do support the repeat character feature?
(In reply to Dr. Werner Fink from comment #60) > Questions:a) whern will the ncurses version from Base:System reach > Tumbleweed I don't see any pending requests in https://build.opensuse.org/package/requests/openSUSE:Factory/ncurses so I guess you refer to https://build.opensuse.org/request/show/527053 that was accepted 7 days ago. According to https://build.opensuse.org/project/dashboard/openSUSE:Factory/ the snapshot under current testing is 20170924 which should include your update but the snapshot was not yet released because there are still some openQA test failures unaccounted for on https://openqa.opensuse.org/tests/overview?distri=opensuse&version=Tumbleweed&group=openSUSE%20Tumbleweed but I assume the new version will be published today as I read out from the chat log on [#opensuse-factory](irc://chat.freenode.net/opensuse-factory) and b) whern will this happen for SLES-15 https://build.suse.de/request/show/141972 is the last auto-submit 5 days ago and already accepted which looks like including the same state as for https://build.opensuse.org/request/show/527053 so the new build should also include that already.
It's good to install LeanOS via ssh terminal with alpha 5 candidate build(278.1) , no ncurses rendering issue.
Nitpicking: The attached "shell script rep.tst" contains commands like "rep 108 0". REP, by its nature, contains an important off by one. E.g. to print a character 20 times in total, you print it first and then repeat it 19 times. Apparently the "tput rep" command expects to receive 20 as its argument in this case, and subtracts one for the generated repeater escape sequence "\e[19b". As a result, "tput rep 108 0" prints the letter "l" once, followed by "\e[-1b" as if it was a valid escape sequence to repeat it -1 times. xterm silently swallows this, resulting in "l" appearing once. VTE's (gnome-terminal's) forthcoming patch will display garbage. konsole also displays garbage. I don't think "rep 108 0" or its emitted escape sequence "\e[-1b" are valid ones and I don't think any particular behavior is expected here from terminal emulators.
(In reply to Egmont Koblinger from comment #65) > Nitpicking: > > The attached "shell script rep.tst" contains commands like "rep 108 0". > > REP, by its nature, contains an important off by one. E.g. to print a > character 20 times in total, you print it first and then repeat it 19 times. > Apparently the "tput rep" command expects to receive 20 as its argument in > this case, and subtracts one for the generated repeater escape sequence > "\e[19b". > > As a result, "tput rep 108 0" prints the letter "l" once, followed by > "\e[-1b" as if it was a valid escape sequence to repeat it -1 times. > > xterm silently swallows this, resulting in "l" appearing once. VTE's > (gnome-terminal's) forthcoming patch will display garbage. konsole also > displays garbage. > > I don't think "rep 108 0" or its emitted escape sequence "\e[-1b" are valid > ones and I don't think any particular behavior is expected here from > terminal emulators. I've added your comment to bug boo#1056020
... And in turn I've made a comment over there which might be relevant here too (bug 1056020 comment 25).
*** Bug 1067491 has been marked as a duplicate of this bug. ***
What is the status with this bug and current ncurses version as well as current versions of the various terminal emulators used with TERM=xterm*
Looking good on the latest tumbleweed!
Please double check konsole with an 8-bit charset (and a corresponding 8-bit locale for ncurses apps)! According to my latest memories, ncurses-20170823-ish changed to only use REP under 8-bit locales. The konsole bugreport is still open, there was no activity (not even a comments from developers, let alone a proposed patch). Unless ncurses has since completely backed off from using REP, or SUSE changed ncurses, terminfo or konsole downstream, this combination should still be broken.
Oops, in that case please reopen the bug.
It's only a strong suspicion from me, I haven't verified and cannot verify since I'm not running SUSE. Anyway, let's err on the safe side, reopening for someone to double check.
(In reply to Egmont Koblinger from comment #71) > Please double check konsole with an 8-bit charset (and a corresponding 8-bit > locale for ncurses apps)! > > According to my latest memories, ncurses-20170823-ish changed to only use > REP under 8-bit locales. The konsole bugreport is still open, there was no > activity (not even a comments from developers, let alone a proposed patch). > > Unless ncurses has since completely backed off from using REP, or SUSE > changed ncurses, terminfo or konsole downstream, this combination should > still be broken. Which bug report for konsole does cover this?
> Which bug report for konsole does cover this? https://bugs.kde.org/show_bug.cgi?id=384620
(In reply to Egmont Koblinger from comment #75) > > Which bug report for konsole does cover this? > > https://bugs.kde.org/show_bug.cgi?id=384620 Luca? What is the status here?
So far, unfortunately, no upstream activity on this front.
(In reply to Luca Beltrame from comment #77) > So far, unfortunately, no upstream activity on this front. Hmmm ... would be perfect if the rep support could be added to konsole as most users do use TERM=xterm and not TERM=konsole
I'm not able anymore to login at https://bugs.kde.org/ ... looks like a disabled account
OK ... there is something new at https://bugs.kde.org/show_bug.cgi?id=384620 Luca? Is the kconsole upto date now on Factory aka next Tumbleweed?
The change highlighted (https://phabricator.kde.org/D10064) is still not merged upstream. We could add it to our package as a workaround.
(In reply to Luca Beltrame from comment #81) > The change highlighted (https://phabricator.kde.org/D10064) is still not > merged upstream. We could add it to our package as a workaround. Ah ... yep, I think so
Please can you tell me what is the status here?
(In reply to Dr. Werner Fink from comment #83) > Please can you tell me what is the status here? I won't have time until the weekend to look into it. If any other member of the KDE team is willing to, feel free to do so.
Just ported and added the Diff 25855 from to konsole-17.12.1, see SR#571633 please consider to review and if possible to accept and forward this ASAP beause we have several products like Leap15 and SLES15 as well as Tumbleweed user out there
(In reply to Dr. Werner Fink from comment #83) > Please can you tell me what is the status here? The only remaining question is whether konsole should check that it actually is a printable character. Doesn't matter much though I suppose, as the standard explicitly says the behaviour is undefined for non-printable characters. Btw, sorry for the late response, I haven't followed *this* bug report (which was/is about xterm, isn't it?). I actually backported and tested the patch a week ago, and would have submitted it already if I read this earlier (I was waiting for further actions upstream). I backported it to konsole4-part as well btw, but I think I'll better wait for the final upstream commit. That is probably not so important anyway, as there are only one or two KDE4 applications left that use it. PS: as the konsole patch has been handled here now, I think we should mark bug 1056020 as duplicate... ;-)
Can confirm. Line editing is broken, back-space causes cursor to forward-space. Root's normal red font is now green. Changing from xterm-256color to xterm fixes immediate problem.
(In reply to Tad Bilby from comment #88) > Can confirm. Line editing is broken, back-space causes cursor to > forward-space. Root's normal red font is now green. Changing from > xterm-256color to xterm fixes immediate problem. Does this also happen in real XTerm its self ... ?
No. xterm properly "back spaces". koi8rxterm also works properly. The problem is related to konsole. NAME="openSUSE Tumbleweed" # VERSION="20180205 Linux localhost.localdomain 4.15.0-1-default #1 SMP PREEMPT Wed Jan 31 07:03:28 UTC 2018 (ac01747) x86_64 x86_64 x86_64 GNU/Linux konsole 17.04.2
(In reply to Tad Bilby from comment #90) > No. xterm properly "back spaces". koi8rxterm also works properly. The > problem is related to konsole. > NAME="openSUSE Tumbleweed" > # VERSION="20180205 > Linux localhost.localdomain 4.15.0-1-default #1 SMP PREEMPT Wed Jan 31 > 07:03:28 UTC 2018 (ac01747) x86_64 x86_64 x86_64 GNU/Linux > konsole 17.04.2 This bug is related to xterm AFAICS from subject and not konsole using TERM=xterm nor TERM=xterm-256color Could you please test out the latest konsole package with the REP workaround I had submitted to Factory Thu Feb 1 08:57:19 UTC 2018 - werner@suse.de - Temporary add patch konsole-D10064.id25855.diff which is based on the Diff 25855 from https://phabricator.kde.org/D10064 for Support of ECMA-48 REP (boo#1054448, bsc#1078565, and kde#384620) from https://download.opensuse.org/repositories/KDE:/Applications/KDE_Frameworks5_openSUSE_Tumbleweed/ if this does not help then you might clone this bug, correct the subject to get the konsole fixed and not xterm nor ncurses as the last two one are not broken. Then I'm able to close this but (after removing the bug dependencies)
Next is all other terminal emulators like in gnome, in xfce4 oand other whic hare used with TERM=xterm(-whatever): do they work together with ncurses and its correct terminfo entry for the XTerm? If not please clone this bug and adapt the subject for the specific terminal emulator so that we get those fixed (e.g. support of the REP feature of the XTerm)
(In reply to Tad Bilby from comment #90) > No. xterm properly "back spaces". koi8rxterm also works properly. The > problem is related to konsole. Note that konsole uses TERM=xterm-256color by default, while xterm uses TERM=xterm. According to some mails on the opensuse-factory mailing list, the current problems seem to be reproducible in xterm too by setting TERM=xterm-256color.
(In reply to Wolfgang Bauer from comment #93) > (In reply to Tad Bilby from comment #90) > > No. xterm properly "back spaces". koi8rxterm also works properly. The > > problem is related to konsole. > > Note that konsole uses TERM=xterm-256color by default, while xterm uses > TERM=xterm. > According to some mails on the opensuse-factory mailing list, the current > problems seem to be reproducible in xterm too by setting TERM=xterm-256color. If konsole claims to be XTerm compatible and it is not then this is a bug of konsole and not from ncurses nor XTerm^[1]. There exists an TERMINFO entry konsole-256color ... beside this I do not see how konsole uses ncurses at all shell> ldd /usr/bin/konsole | grep -E 'lib(ncurses|tinfo|panel|form)' shell> ldd /usr/bin/xterm | grep -E 'lib(ncurses|tinfo|panel|form)' libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f65f3f9e000) don't know if konsole tries to read features from TERMINFO entries but if and as the API and the format of the terminfo entries are changed with latest ncurses I'd like to recomment to use at least libtinfo.so.6.1 as otherwise things will not work. [1]Otherwise it would be never possible to develop new features for XTerm supported by the TERMINFO entry xterm or xterm-256color
(In reply to Dr. Werner Fink from comment #94) > (In reply to Wolfgang Bauer from comment #93) > > (In reply to Tad Bilby from comment #90) > If konsole claims to be XTerm compatible and it is not then this is a bug of > konsole and not from ncurses nor XTerm^[1]. But if setting TERM=xterm in konsole fixes the problem, and setting TERM=xterm-256color in xterm causes it in xterm as well, it might rather be a bug in ncurses' xterm-256color, no? I haven't tried though. > There exists an TERMINFO entry > konsole-256color ... beside this I do not see how konsole uses ncurses > at all Of course konsole doesn't use ncurses. But it sets TERM=xterm-256color by default.
PS, just noticed this: (In reply to Tad Bilby from comment #90) > konsole 17.04.2 Is this really true? The current konsole version in Tumblweed is 17.12.1, and does contain the added REP support. 17.04.2 is Leap 42.3's version.
FWIW, I just booted a Kryption LiveCD (based on latest Tumbleweed, but uses the unstable KDE packages), and didn't notice any problem in Konsole. In particular line editing/backspace worked fine, and the prompt color in root mode is red. That's with the default settings, i.e. TERM=xterm-256color, and ncurses/terminfo-base 6.1.
Please pay attention to comment 71, and try to see if you can still reproduce the bug with unpatched konsole (and then the patch hopefully indeed fixing it) under an 8-bit (non UTF-8) locale.
(In reply to Dr. Werner Fink from comment #92) > Next is all other terminal emulators like in gnome, in xfce4 oand other whic > hare used with TERM=xterm(-whatever): do they work together with ncurses and > its correct terminfo entry for the XTerm? VTE (the terminal emulation engine behind gnome-terminal, xfce4-terminal and a whole lot more) added REP support in version 0.50.1.
(and backported to 0.48.4 and 0.46.3 too)
(In reply to Dr. Werner Fink from comment #94) > don't know if konsole tries to read features from TERMINFO entries [...] Just FYI: The traditional approach is that first the terminal emulator does something, and then the terminfo file describes it. The only exception I'm aware of that used to work the other way around, trying to behave as described in terminfo, was VTE up to version perhaps 0.38 or 0.40. The approach was problematic for various reasons. One being that many of the features, escape sequences aren't described in terminfo. Another problematic one is features that consist of multiple escape sequences. E.g. clear is typically "\e[H\e[2J". If an app wants to clear the screen, it can look it up and print it and it doesn't need to worry about it actually being two escape sequences. What about a terminal emulator, though? It would know that "\e[H\e[2J" means to clear, but what the heck to do upon seeing one or the other only? It couldn't know. That's why this approach was ditched in VTE too, making it no longer depend on libtinfo. I'm not aware of any terminal emulator taking this approach. > [1]Otherwise it would be never possible to develop new features for XTerm > supported by the TERMINFO entry xterm or xterm-256color This isn't solved for xterm itself either, assuming that users might ssh across systems. The whole approach with the TERM variable referring to a local file, and then only this variable getting forwarded across ssh is a broken concept. IMO it's way beyond the scope of this bugreport to design, let alone implement and adopt something better.
(In reply to Egmont Koblinger from comment #98) > Please pay attention to comment 71, and try to see if you can still > reproduce the bug with unpatched konsole (and then the patch hopefully > indeed fixing it) under an 8-bit (non UTF-8) locale. Haven't tried under an 8-bit locale, but I was able to reproduce the broken rendering with the ncurses box test from the KDE bug report and the rep.tst from here, and it was fixed with the patch. I tested this 2 weeks ago already. The latest replies were addressing Ted Bilby's comments about line editing (backspace) being broken. (which has nothing to do with this bug report anyway IMHO)
(In reply to Wolfgang Bauer from comment #102) > Haven't tried under an 8-bit locale, but I was able to reproduce the broken > rendering with the ncurses box test from the KDE bug report and the rep.tst > from here, and it was fixed with the patch. Cool, I overlooked it then, sorry.
(In reply to Wolfgang Bauer from comment #96) > PS, just noticed this: > (In reply to Tad Bilby from comment #90) > > konsole 17.04.2 > > Is this really true? > The current konsole version in Tumblweed is 17.12.1, and does contain the > added REP support. > > 17.04.2 is Leap 42.3's version. I'm uncertain to run zypper dup. I believe that would update my console version. I running "zypper up -l --replacefiles -y" and konsole is not updating. I have read that I can create an unstable system since I use the packman repo for multimedia codecs and extensions. zypper dup --allow-vendor-change ## 1st choice, lots of pkgs changed! zypper dup --no-allow-vendor-change ## safer option?!
(In reply to Wolfgang Bauer from comment #96) > PS, just noticed this: > (In reply to Tad Bilby from comment #90) > > konsole 17.04.2 > > Is this really true? > The current konsole version in Tumblweed is 17.12.1, and does contain the > added REP support. > > 17.04.2 is Leap 42.3's version. OK, I upgraded to konsole 17.12.1, back-space is still broken. $ konsole -v konsole 17.12.1 I'll try to locate the other bug that Dr. Fink thinks this should be filed under. I have to say that I have VPN app which uses ncurses which has been broken for a while. It used to display properly. I have uploaded a screen shot of the app with ncurses not displaying properly.
Created attachment 759471 [details] screenshot of ncurses not displaying correctly. This should be a square box.
It looks like the xterm-256color terminfo file is the issue. $ infocmp infocmp: couldn't open terminfo file /usr/share/terminfo/x/xterm-256color # zypper in terminfo No update candidate for 'terminfo-6.1-1.1.x86_64'. The highest available version is already installed $:/usr/share/terminfo/x> file xterm-256color xterm-256color: Compiled 32-bit terminfo entry "xterm-256color" $:/usr/share/terminfo/x> file xterm xterm: Compiled terminfo entry "xterm"
(In reply to Tad Bilby from comment #104) > I'm uncertain to run zypper dup. I believe that would update my console > version. > > I running "zypper up -l --replacefiles -y" and konsole is not updating. > > I have read that I can create an unstable system since I use the packman > repo for multimedia codecs and extensions. > > zypper dup --allow-vendor-change ## 1st choice, lots of pkgs changed! > zypper dup --no-allow-vendor-change ## safer option?! The only recommended way to update Tumbleweed is "zypper dup", not "zypper up". And "--no-allow-vendor-change" is the default on TW since a while, you should not have to specify it. I'm wondering why you still had konsole 17.04.2 though. Sure that you haven't added some Leap 42.3 repos? (In reply to Tad Bilby from comment #106) > Created attachment 759471 [details] > screenshot of ncurses not displaying correctly. > > This should be a square box. Hm, you did restart konsole (or reboot) after updating, did you? (In reply to Tad Bilby from comment #107) > It looks like the xterm-256color terminfo file is the issue. > $ infocmp > infocmp: couldn't open terminfo file /usr/share/terminfo/x/xterm-256color > # zypper in terminfo > No update candidate for 'terminfo-6.1-1.1.x86_64'. The highest available > version is already installed > $:/usr/share/terminfo/x> file xterm-256color > xterm-256color: Compiled 32-bit terminfo entry "xterm-256color" > $:/usr/share/terminfo/x> file xterm > xterm: Compiled terminfo entry "xterm" That seems to be normal.
(In reply to Egmont Koblinger from comment #101) > > > [1]Otherwise it would be never possible to develop new features for XTerm > > supported by the TERMINFO entry xterm or xterm-256color > > This isn't solved for xterm itself either, assuming that users might ssh > across systems. The whole approach with the TERM variable referring to a > local file, and then only this variable getting forwarded across ssh is a > broken concept. IMO it's way beyond the scope of this bugreport to design, > let alone implement and adopt something better. ncurses 6.1 has a new 32bit format for e.g. xterm-256color and if konsole can not read this do not using libtinfo then this is not a bug of ncurses. If a user or the system setup uses xterm-256color even if it is known that a remote system can not handle this as xterm-256color is not known then this is also not a bug for ncurses (In reply to Wolfgang Bauer from comment #108) > (In reply to Tad Bilby from comment #107) > > It looks like the xterm-256color terminfo file is the issue. > > $ infocmp > > infocmp: couldn't open terminfo file /usr/share/terminfo/x/xterm-256color > > # zypper in terminfo > > No update candidate for 'terminfo-6.1-1.1.x86_64'. The highest available > > version is already installed > > $:/usr/share/terminfo/x> file xterm-256color > > xterm-256color: Compiled 32-bit terminfo entry "xterm-256color" > > $:/usr/share/terminfo/x> file xterm > > xterm: Compiled terminfo entry "xterm" > > That seems to be normal. Does konsole read any information from an terminfo entry specified by the TERM variable? If this is done (xterm does it) how this is done? If onw code in konsole or the QT/KDE libraries does this, then the question rises if this code can handle 32bit terminfo entries? The libtinfo 6.1 can handle this extend format
(In reply to Egmont Koblinger from comment #101) > (In reply to Dr. Werner Fink from comment #94) > > > don't know if konsole tries to read features from TERMINFO entries [...] > > Just FYI: > > The traditional approach is that first the terminal emulator does something, > and then the terminfo file describes it. Ahm ... belive me I'm aware now more then 20 years about this fact ... nevertheless there is code in XTerm which e.g. reads the terminfo entry for xterm and then decide what should be send for the keys kbd and BS ;)
(In reply to Dr. Werner Fink from comment #109) > (In reply to Wolfgang Bauer from comment #108) > Does konsole read any information from an terminfo entry specified by the > TERM variable? If this is done (xterm does it) how this is done? I don't know, would need to check the code. But I don't really think so. And I haven't seen any problem here as mentioned, the ncurses rendering was fine now too in my tests. (of course I didn't try that particular "VPN app") Konsole does allow to explicitly configure the keyboard mapping in its profile settings, that may be the reason for the backspace problem. The defaults should work fine though from my POV.
PS: I just did a grep for "terminfo" over the whole konsole source code and didn't get any hits (except for some README files). I suppose it should have found something if konsole itself would really try to open a file in /usr/share/terminfo/...
(In reply to Wolfgang Bauer from comment #111) > > I don't know, would need to check the code. > But I don't really think so. > And I haven't seen any problem here as mentioned, the ncurses rendering was > fine now too in my tests. (of course I didn't try that particular "VPN app") Guess: the "VPN app" is based in slang library ... compare with bug #1079543 against slang library
(In reply to Dr. Werner Fink from comment #113) > (In reply to Wolfgang Bauer from comment #111) > > > > I don't know, would need to check the code. > > But I don't really think so. > > And I haven't seen any problem here as mentioned, the ncurses rendering was > > fine now too in my tests. (of course I didn't try that particular "VPN app") > > Guess: the "VPN app" is based in slang library ... compare with bug #1079543 > against slang library Here are the libaries opened by the VPN app. It's the barracuda VPN. Let me know and I will include the full strace dump. open("/opt/phion/libs64/engines/libcavium.so", O_RDONLY) = -1 ENOENT (No such file or directory) lstat("/lib/terminfo", 0x1a7f480) = -1 ENOENT (No such file or directory) stat("/lib/terminfo", 0x1a7f480) = -1 ENOENT (No such file or directory) I renamed xterm-256color xterm-256color.bad and copied xterm over xterm-256color and now the box renders properly. I have attached the new image. Back-space works "of course" once again since I am not using xterm-256color in konsole currently.
Created attachment 759648 [details] ncurses rendering properly Here is a screen shot of an ncurses app properly rendering.
(In reply to Tad Bilby from comment #114) > (In reply to Dr. Werner Fink from comment #113) > > (In reply to Wolfgang Bauer from comment #111) > > > > > > I don't know, would need to check the code. > > > But I don't really think so. > > > And I haven't seen any problem here as mentioned, the ncurses rendering was > > > fine now too in my tests. (of course I didn't try that particular "VPN app") > > > > Guess: the "VPN app" is based in slang library ... compare with bug #1079543 > > against slang library > > Here are the libaries opened by the VPN app. It's the barracuda VPN. Let > me know and I will include the full strace dump. > > open("/opt/phion/libs64/engines/libcavium.so", O_RDONLY) = -1 ENOENT (No > such file or directory) > lstat("/lib/terminfo", 0x1a7f480) = -1 ENOENT (No such file or > directory) > stat("/lib/terminfo", 0x1a7f480) = -1 ENOENT (No such file or > directory) > > I renamed xterm-256color xterm-256color.bad and copied xterm over > xterm-256color and now the box renders properly. I have attached the new > image. Back-space works "of course" once again since I am not using > xterm-256color in konsole currently. a few more libraries paths used: XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB JAVA_ROOT=/usr/lib64/jvm/jre
(In reply to Tad Bilby from comment #114) > Here are the libaries opened by the VPN app. It's the barracuda VPN. Let > me know and I will include the full strace dump. > > open("/opt/phion/libs64/engines/libcavium.so", O_RDONLY) = -1 ENOENT (No > such file or directory) > lstat("/lib/terminfo", 0x1a7f480) = -1 ENOENT (No such file or > directory) > stat("/lib/terminfo", 0x1a7f480) = -1 ENOENT (No such file or > directory) > > I renamed xterm-256color xterm-256color.bad and copied xterm over > xterm-256color and now the box renders properly. I have attached the new > image. Back-space works "of course" once again since I am not using > xterm-256color in konsole currently. run the command ldd(1) against the binary and its shared files which it does load ... btw, if it does not use libncurses nor libtinfo then it is not ncurses which is used for rendering. Beside this: renaming the 32bit terminfo file to *.bad does not help as ncurses 6.1 is the new standard and I'll not gona change this due third party programs
(In reply to Dr. Werner Fink from comment #117) > (In reply to Tad Bilby from comment #114) > > > Here are the libaries opened by the VPN app. It's the barracuda VPN. Let > > me know and I will include the full strace dump. > > > > open("/opt/phion/libs64/engines/libcavium.so", O_RDONLY) = -1 ENOENT (No > > such file or directory) > > lstat("/lib/terminfo", 0x1a7f480) = -1 ENOENT (No such file or > > directory) > > stat("/lib/terminfo", 0x1a7f480) = -1 ENOENT (No such file or > > directory) > > > > I renamed xterm-256color xterm-256color.bad and copied xterm over > > xterm-256color and now the box renders properly. I have attached the new > > image. Back-space works "of course" once again since I am not using > > xterm-256color in konsole currently. > > run the command ldd(1) against the binary and its shared files which it does > load > ... btw, if it does not use libncurses nor libtinfo then it is not ncurses > which is used for rendering. > > Beside this: renaming the 32bit terminfo file to *.bad does not help as > ncurses 6.1 is the new standard and I'll not gona change this due third > party programs OK, I see. # ldd vpn not a dynamic executable # file vpn vpn: setuid ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, stripped
(In reply to Tad Bilby from comment #118) > > Beside this: renaming the 32bit terminfo file to *.bad does not help as > > ncurses 6.1 is the new standard and I'll not gona change this due third > > party programs > > OK, I see. > > # ldd vpn > not a dynamic executable > # file vpn > vpn: setuid ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically > linked, for GNU/Linux 2.6.9, stripped Hmmm ... could be statically linked against old ncurses or slang library and in both cases 32bit formats are not supported by this binary. You might use a script like this in the path where vpn exists mv vpn vpn.bin (cat > vpn)<<'EOF' #!/bin/bash export TERM=${TERM%-256color*} exec -a vpn vpm.bin ${1+"$@"} EOF chnod 755 vpn
No answer yet
Thank you for the script. Tumbleweed has forced me to do a "clean" upgrade by removing all of the third party repos. ncurses properly displays the menu now with xterm-256color. # file /usr/local/bin/vpn /usr/local/bin/vpn: setuid ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, , stripped LSB_VERSION="core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64" NAME="openSUSE Tumbleweed" # VERSION="20180905" ID="opensuse-tumbleweed" ID_LIKE="opensuse suse" VERSION_ID="20180905" PRETTY_NAME="openSUSE Tumbleweed" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:tumbleweed:20180905" Linux 4.18.5-1-default #1 SMP PREEMPT Fri Aug 24 12:38:43 UTC 2018 (9e91e29) x86_64 x86_64 x86_64 GNU/Linux Time for me to file a new bug. I have a new problem unrelated to this thread.... keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 key The Xauthority error happens when I start any executable as a unprivileged user. I have deleted the .Xauthority file logged out and back in. The binary runs properly. Thanks again, Tad
This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: create_hdd_ha_textmode https://openqa.suse.de/tests/5911490 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" 3. The label in the openQA scenario is removed
The results seen at https://openqa.suse.de/tests/5911490 do show missing rep feature of terminals ... why does this bot report this?
(In reply to Dr. Werner Fink from comment #123) > The results seen at https://openqa.suse.de/tests/5911490 do show missing rep > feature of terminals ... why does this bot report this? I assume you mean the comment in https://bugzilla.opensuse.org/show_bug.cgi?id=1054448#c122 Well, https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/7d0a7d2d5ab59ca958a4c3f8450d4598fe944960/tests/installation/bootloader_zkvm.pm#L87 references this bug here whenever the conditions in code are met which happened in recent job runs as for example the referenced one. @mgriessmeier as you are the maintainer of the test module bootloader_zkvm asking you for info. Likely you want to forward to another team and ensure the maintainer is updated.
This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: create_hdd_ha_textmode https://openqa.suse.de/tests/5924008 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" 3. The label in the openQA scenario is removed
This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: create_hdd_textmode https://openqa.suse.de/tests/5989991 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" 3. The label in the openQA scenario is removed
This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: create_hdd_textmode https://openqa.suse.de/tests/5989991 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" or "EOL" (End-of-Life) 3. The label in the openQA scenario is removed