Yast2-ncurses broken?

I’ve tested the following on several machines (From Atom330 up to an e235 IBM Server) under 11.2:

The last Update “Yast2-ncurses” destroys the “online Update” and the Software Management" within YaST, if YaST is used on a shell (not on KDE).

I’m able to start the tools, they are reading the repositories and then fall back to the YaST main menu without any further comment.

Sometimes it’s possible to get the menu of the software management - just trying a search for a packet kills the application and it falls back to the main menu.

If the “YaST2-ncurses” Update is suppressed, it remains working, as far as i tried up to now.

Will this be fixed? I’m running several Gateways without KDE and it is nasty if YaST can’t be used.

And: How to install a fix or patch without using YaST? Zypper?

Sincerely
Shardan
(Sorry for my english, i’m german)

> Will this be fixed?

depends on if a bug has been logged…you can check:
http://en.opensuse.org/Submitting_Bug_Reports

> (Sorry for my english, i’m german)

you english is great! you are welcome here…but, i know it might be
easier at our Deutsch forum: http://www.linux-club.de/


palladium

Hi, I just ran into the same problem. I fixed it by downgrading to the old version of yast2-ncurses:

For OpenSUSE 11.1 on x86_64 arch:


# wget http://download.opensuse.org/distribution/11.1/repo/oss/suse/x86_64/yast2-ncurses-2.17.11-1.25.x86_64.rpm
# rpm -Uvh --oldpackage yast2-ncurses-2.17.11-1.25.x86_64.rpm

Thanks to: Re: [opensuse] zypper help

gwyn

Let’s see what’s broken. The backend of YaST Software is zypper. If zypper still works, then we can fix this easily. First let’s find out what repos you have.

zypper lr -d

I suspect that you have a Qt repo in there that is throwing things off. If this is the case, then please disable the repo. Once that is done, then we might be able to use zypper to fix it.

zypper in *yast*

Notice I put the * before and after yast. This will cause zypper to install everything that has yast in the name.


QT should not effect the cursors version it is pure terminal.

I tested it here before and after the upgrade the CL version is broken.

Also a small thing but there was no way to reject the upgrade from the updater. You can uncheck the package and it does not get installed but the updater immediately informed me that the upgrade was available again. I could go into the management window and lock the version but this should be available from the updater window. There also should be an option to show locked packages that may have upgrades available. There should be the option for those that want to skip a broken upgrade but may want to catch the next one.

It can. If one is using the Qt YaST and does an upgrade, and the Qt is broken and zypper/YaST tries to solve this but the user incorrectly selects the wrong combination, it can break the ncurses to.

> rpm -q --whatrequires yast2-ncurses
yast2-ncurses-pkg-2.18.4-2.9.x86_64
patterns-openSUSE-yast2_install_wf-11.2-20.22.1.x86_64
patterns-openSUSE-yast2_basis-11.2-20.22.1.x86_64
yast2-ncurses-devel-2.18.10-2.1.x86_64
yast2-ncurses-devel-2.18.10-2.1.x86_64

So if patterns-openSUSE-yast2 yada yada yada was deleted then that would do it. Or…if any of these were deleted.

 rpm -q --requires yast2-ncurses
glibc-locale                                         
yast2-libyui >= 2.18.4                               
rpmlib(PayloadFilesHavePrefix) <= 4.0-1              
rpmlib(CompressedFileNames) <= 3.0.4-1               
libc.so.6()(64bit)                                   
libc.so.6(GLIBC_2.2.5)(64bit)                        
libc.so.6(GLIBC_2.3.4)(64bit)                        
libc.so.6(GLIBC_2.4)(64bit)                          
libgcc_s.so.1()(64bit)                               
libgcc_s.so.1(GCC_3.0)(64bit)                        
libncursesw.so.5()(64bit)                            
libpanelw.so.5()(64bit)                              
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libstdc++.so.6()(64bit)
libstdc++.so.6(CXXABI_1.3)(64bit)
libstdc++.so.6(GLIBCXX_3.4)(64bit)
libstdc++.so.6(GLIBCXX_3.4.11)(64bit)
libstdc++.so.6(GLIBCXX_3.4.9)(64bit)
libyui.so.3()(64bit)
rpmlib(PayloadIsLzma) <= 4.4.6-1

Since my install is plain vanilla install no extra repositories and the upgrade did break software management in Yast-cursors. (Note: Yast runs it just does not run the management modual!) This certainly appears to me that the update is broken. Personally I don’t use the CL version very often but there are those that manage machines via remote that do need it to manage their machines. So I think this is a pretty big deal.

When I saw the OP post I had not yet updated. I tried yast from CL and it ran fine I could get to the management screen. I ran the updater and updated the package. tried again and yast ran but went back to the main Yast screen after it finished checking the repositories rather then going on to the management screen.

This update is broken!

Have you tried zypper yet?
What repos do you have?

 zypper lr -d

Bug reported here : https://bugzilla.novell.com/show_bug.cgi?id=569000

Please downgrade to an older version in the meantime:

zypper in -C yast2-ncurses=2.18.10

(for oS 11.2)

I did check, and have confirmed that the package does break YaST. I confirmed that even though it breaks YaST, zypper works fine.

There is a bug open on this: https://bugzilla.novell.com/show_bug.cgi?id=569000


Welcome to my first day after loading OpenSuSE 11.2 – Thanks to the forum I am considerably less frustrated when what I knew to work back in Suse 9.xx from a long time ago suddenly did not work any more when the documentation said it should.

I want to confirm pasha’s bug. I too did a weekend maintenance update and Command Line, CL, Yast will not run Software Update or Software Management. The CL is my preferred way to run updating. I go to init 3 before updating, it usually works. KDE based yast looks like it is working but CL is not.

There were a list of about 10 items to upgrade. Someone will have to tell which logs to examine to find the problem and what happened.

Also the GRUB menu was altered as a kernel upgrade was included in the update set. This creates complete confusion when it is unannounced. Please find a different way to altering and communicating that to everyone. The unexpected is the problem.

It appears this CL Yast problem has occurred in the past, 2008. I do not know the internal testing process and procedures but I think you need to add this problem to your test suite. It should be run prior to all releases.

Software testing has undergone a revolution in the last 20 years. SUSE should take advantage of those improvements. Test, test, test…

zypper works fine Yast GUI works fine it is just yast-curses that is broken. Personally it is no problem for me, I was just confirming the original poster’s observations.

I have applied the downgrade and it worked for me. I will watch the bug report. Thank you for your help.

I tried the rollback and it said there was “nothing to do” and did not fix the problem. I am currently reloading – no loss except for time. When I get reloaded, should I online update everything EXCLUDING yast2-ncurses or should I update NOTHING until this is fixed? Is the bug report listed earlier the best place to determine when this is fixed?

No, that rollback should have worked, unless you didn’t have the base repo registered or something odd. Reinstalling was a rather extreme response.

I had just freshly loaded the system today – the first thing I did was an online update. – really no loss except for time.

But a problem like that would have been a symptom of something odd which might bite you later. Reinstalling may have fixed the problem but destroyed the evidence and you missed the chance to understand how the repos work.

Stated very well. I hold the exact same philosophy.

In troubleshooting, I try never to format and reinstall. Why? There is a sequence of events that lead up to the current situation. Even if you “fix” the problem, say its a Windows computer with a virus, and you clean the virus out, until you deal with the behavior, its going to occur again. So I prefer to not just troubleshoot my customers computers, but educate them as to what happened, why, and how they can avoid that in the future.

Ok, now this your chance to give some tutoring. How can the logs help determine what happened?