Opensuse Leap 15.5 – YaST2 bug – no repositories can be added via YaST2

Posted on by

In one of the last posts I have said that upgrades of running Opensuse Leap 15.4-systems to Leap 15.5 are a smooth business. However, a major bug in the present Leap 15.5 did not appear on my radar until now.

During the upgrades of most of my systems I just continued using a system-specific bunch of active Opensuse repositories – like the “graphics” and the “security” repositories. I used the ${releasever}-mechanism during the upgrades to point zypper to the new versions of the repositories. This all went well and after the upgrade I found the 15.5-versions of those repositories, which I had used on Leap 15.4 before, integrated into the YaST2-software and package management of Leap 15.5.

But, two days ago, I installed Leap 15.5 on a laptop from an ISO-image on a DVD. Such an installation only sets up basic Leap 15.5 repositories. So, after the installation I wanted to add further repositories via YaST2’s software-management. This did not work at all. The repositories simply did not appear in the list of managed repositories afterwards.

I fiddled around for about an hour. It became clear by switching views on repos and so called “services” that the requested new repositories were handled by YaST as SW-services, instead as standard repositories. Whatever “services” are going to be good for in the future. I could find some information at
https://news.opensuse.org/ 2023/07/31/ try-out-cdn-with-opensuse-repos/.

I moved in the end to zypper on the command line to add repositories. Which worked …. A good reason to suspect a bug.

Bug: Adding repositories with YaST2 does not work presently

Indeed: The following two links showed that other Opensuse users had the same problem and that there is a related bug-entry at Opensuse’s bugzilla:
https://forums.opensuse.org/ t/ cant-add-repos/ 171641
https://bugzilla.opensuse.org/ show_bug.cgi?id=1218399

Well, YaST2 is a central tool-box for Opensuse systems. And who would deny that the package manager is one of the most important tools on any Linux system? So, old kinds of questions regarding quality assurance came to my mind: Are changes to central Leap components tested thoroughly at Opensuse? In particular as also SLES is affected …. Unbelievable …

The affected package is yas2-packager 4.5.17-150500.3.3.1.

Workaround

Adding repositories directly via zypper (which is used by YaST2) still works. So, you can add add repositories like the security repository, with command analogous to the following: 

mytux:~ # zypper ar -f https://download.opensuse.org/repositories/security/15.5 security
Adding repository 'security' 
..................................................................................[done]
Repository 'security' successfully added

URI         : https://download.opensuse.org/repositories/security/15.5
Enabled     : Yes
GPG Check   : Yes
Autorefresh : Yes
Priority    : 99 (default priority)

Repository priorities are without effect. All enabled repositories share the same priority.

These repos afterward appear in the YaST2 packet manger and are fully usable to install RPM packages.

Weird aspect of the YaST2 packet manager: Opensuse and Nvidia services cannot be deleted via YaST2

After some updates of leap 15.5 you may find that all basic repositories have been switched to “services” at “cdn.opensuse.org”. What is disturbing: A fresh installation of Leap 15.5 from an ISO-image does not show any of the services displayed in the image above.

Once you got the “services” in your Leap 15.5 installation you may want to delete them and restrict your system to the standard repositories at “download.opensuse.org”. But this does not work with YaST2. Which appears as an additional bug. You may switch to “services” and delete them in the views coming up. And everything afterward gives you the impression that they are gone. But no: After a restart of YaST2 and the packet manager all Opensuse services appear restored again.

Conclusion

YaST2’s present packet manager for Leap 15.5 has a major bug: Repositories can not be added. In addition one cannot get rid of the new Opensuse services. Let us hope that we get a new and error free version of YaST2’s packet manager soon.

Combining Jupyterlab, QtAgg, Matplotlib and PyQt

Posted on by

For a variety of reasons I have recently started to study options to write PyQt applications which are directly started from a Python3 notebook in Jupyterlab and are displayed on the Linux desktop.

Without blocking further code execution in other notebook cells and without compromising interactivity both of the notebook and the Qt windows.

Due to the support of QtAgg you do not need any blocking “app.exec_()” statements. You just construct your PyQt windows (with Qt-widgets and integrated Matplotlib figures) and afterward show them on your Linux desktop.

In addition it is rather easy to move activities, objects, methods to background threads controlled by QThread-objects. Worker objects in such threads can communicate with Qt windows and widgets in the foreground via signals, which end up in a thread-safe and serialized way in the Qt event-loop in the main thread. From there they are picked up and handled by callbacks.

I found this a fascinating way on a Linux system with a KDE desktop to use Python in Jupyterlab to create full-fledged Qt-applications and run them under the control of Jupyterlab.

People who are interested find more information in the sister-blog machine-learning.anracom.com.

See the posts

Using PyQt with QtAgg in Jupyterlab – I – a first simple example
Using PyQt with QtAgg in Jupyterlab – II – excursion on threads, signals and events
Using PyQt with QtAgg in Jupyterlab – III – a simple pattern for background threads
Using PyQt with QtAgg in Jupyterlab – IV – simple PyQt and MPL application with background worker and receiver threads

 

Upgrade of PCs and laptops from Opensuse Leap 15.4 to 15.5

Posted on by

The last days I have upgraded multiple PC- and laptop-systems from Leap 15.4 to Leap 15.5. This was one of the smoothest upgrades ever. Despite Nvidia cards, Optimus etc.

In contrast to upgrades in the last years I just kept all special repositories (Nvidia, Packman, Graphics, Security, Print, etc.) active during the upgrade. This worked perfectly.

Suse’s prime-select on an Optimus system just continued working.

To better support Rocca mice on my PC I eliminated old drivers from Rocca and instead used “piper” to set the buttons. My Rocca EMP is basically also well supported by the generic Linux USB mouse driver.

The older I get the more it becomes true:

Linux just works. Why someone uses Windows remains a big mystery to me …

One of the next tasks is to upgrade server systems.