Yes, I now I'm late doing this and it is full of woes. The start-up into X11 has the hourglass spinning for a couple of minutes before the login prompt, and that fails repeatedly. The clue is that in /var/log/messages is 2019-12-01T10:12:52.850103-05:00 MainBox checkproc: checkproc: can not get session id for process 2266! 2019-12-01T10:12:52.851602-05:00 MainBox checkproc: checkproc: can not get session id for process 2266! I don't know what that is. This happens with all possible desktops: KDE, XFCE, Gnome ... ======================================== Logging in with an VT @ F3 and then running xstart I get my KDE to come up, but the system is still crippled. Yes, KDE's bottom bar appears, all the items are in the slots, but mouseover+click does nothing. I can't switch application, can't fire up the gecko menu. Nothing. No clues ==== Of course I've had forceful upgrades of Tbird and FF and lot all my pluings! Oh what an annoyance. Please pardon mis-spelligns and typeos. =================== Mysteriously I get this error message Unable to create io-slave. klauncher said: Error loading '/usr/lib64/qt5/plugins/kf5/kio/trash.so'. And it does exist # ls -l /usr/lib64/qt5/plugins/kf5/kio/trash.so -rwxr-xr-x 1 root root 160176 Jul 16 08:02 /usr/lib64/qt5/plugins/kf5/kio/trash.so # file /usr/lib64/qt5/plugins/kf5/kio/trash.so /usr/lib64/qt5/plugins/kf5/kio/trash.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=f54a37c61b9baf204c9ee7ef09b270b0b7543e11, stripped And trhere is also this Unable to create io-slave. klauncher said: Error loading '/usr/lib64/qt5/plugins/kf5/kio/file.so'. which means that Dolphin doesn't work, so I can't click on my movies, music document to launch them. ===================================== Finally, before giving me advice that might invovle using zypper ... # zypper refresh zypper: symbol lookup error: /usr/lib64/libproxy.so.1: undefined symbol: _ZN9libmodman14module_manager8load_dirENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb I'm dumbfounded and perplexed. =================== # cat /etc/os-release NAME="openSUSE Leap" VERSION="15.0" ID=opensuse ID_LIKE="suse" VERSION_ID="15.0" PRETTY_NAME="openSUSE Leap 15.0" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:leap:15.0" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.opensuse.org/" # uname -a Linux main.HOME.SystemI.ca 5.2.14-2.g7f85414-default #1 SMP Fri Sep 13 11:31:46 UTC 2019 (7f85414) x86_64 x86_64 x86_64 GNU/Linux Thunderbird Version 68.2.2 which means ALL my plugins are now incompatible! ================================= I'm going to set out on the adventure of finding out what other applications I have, my banking, databases, multi-media, all are not 'broken' in terms of what I had crafted and configured for 42.3 -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon?
On 01/12/2019 17.50, Anton Aylward wrote:
Yes, I now I'm late doing this and it is full of woes.
The start-up into X11 has the hourglass spinning for a couple of minutes before the login prompt, and that fails repeatedly. The clue is that in /var/log/messages is 2019-12-01T10:12:52.850103-05:00 MainBox checkproc: checkproc: can not get session id for process 2266! 2019-12-01T10:12:52.851602-05:00 MainBox checkproc: checkproc: can not get session id for process 2266!
I don't know what that is. This happens with all possible desktops: KDE, XFCE, Gnome ...
And what is the process 2266? Look it up in "ps afxu"
========================================
Logging in with an VT @ F3 and then running xstart I get my KDE to come up, but the system is still crippled. Yes, KDE's bottom bar appears, all the items are in the slots, but mouseover+click does nothing. I can't switch application, can't fire up the gecko menu. Nothing. No clues
====
Of course I've had forceful upgrades of Tbird and FF and lot all my pluings! Oh what an annoyance. Please pardon mis-spelligns and typeos.
===================
Mysteriously I get this error message
Unable to create io-slave. klauncher said: Error loading '/usr/lib64/qt5/plugins/kf5/kio/trash.so'.
And it does exist # ls -l /usr/lib64/qt5/plugins/kf5/kio/trash.so -rwxr-xr-x 1 root root 160176 Jul 16 08:02 /usr/lib64/qt5/plugins/kf5/kio/trash.so # file /usr/lib64/qt5/plugins/kf5/kio/trash.so /usr/lib64/qt5/plugins/kf5/kio/trash.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=f54a37c61b9baf204c9ee7ef09b270b0b7543e11, stripped
No, run "rpm -qfi /usr/lib64/qt5/plugins/kf5/kio/trash.so"
And trhere is also this Unable to create io-slave. klauncher said: Error loading '/usr/lib64/qt5/plugins/kf5/kio/file.so'. which means that Dolphin doesn't work, so I can't click on my movies, music document to launch them.
Same thing.
=====================================
Finally, before giving me advice that might invovle using zypper ...
# zypper refresh zypper: symbol lookup error: /usr/lib64/libproxy.so.1: undefined symbol:
_ZN9libmodman14module_manager8load_dirENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb Hum! You
have the wrong version of those files. cer@Telcontar:~> rpm -qf /usr/lib64/libproxy.so.1 libproxy1-0.4.15-lp151.3.3.x86_64 cer@Telcontar:~> Mine has the string lp151. You should have lp150. You will need some jumping skills, like using a rescue system to update this one. Or using rpm perhaps. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 01/12/2019 13:18, Carlos E. R. wrote:
On 01/12/2019 17.50, Anton Aylward wrote:
Yes, I now I'm late doing this and it is full of woes.
The start-up into X11 has the hourglass spinning for a couple of minutes before the login prompt, and that fails repeatedly. The clue is that in /var/log/messages is 2019-12-01T10:12:52.850103-05:00 MainBox checkproc: checkproc: can not get session id for process 2266! 2019-12-01T10:12:52.851602-05:00 MainBox checkproc: checkproc: can not get session id for process 2266!
I don't know what that is. This happens with all possible desktops: KDE, XFCE, Gnome ...
And what is the process 2266? Look it up in "ps afxu"
This time round 2019-12-01T10:12:52.850103-05:00 MainBox checkproc: checkproc: can not get session id for process 2266! 2019-12-01T10:12:52.851602-05:00 MainBox checkproc: checkproc: can not get session id for process 2276! main:/var/log # # ps afxu | grep 2266 root 9974 0.0 0.0 7076 880 pts/4 S+ 13:34 0:00 | \_ grep --color=auto 2266 and main:/var/log # ps afxu | grep 2276 root 9977 0.0 0.0 7076 896 pts/4 S+ 3:34 0:00 | \_ grep --color=auto 2276 Unhelpful. I think that it is a transient process in the login, and when failed, it an ancestors evaporates and it foes back to the login prompt box.
========================================
Logging in with an VT @ F3 and then running xstart I get my KDE to come up, but the system is still crippled. Yes, KDE's bottom bar appears, all the items are in the slots, but mouseover+click does nothing. I can't switch application, can't fire up the gecko menu. Nothing. No clues
====
Of course I've had forceful upgrades of Tbird and FF and lot all my pluings! Oh what an annoyance. Please pardon mis-spelligns and typeos.
===================
Mysteriously I get this error message
Unable to create io-slave. klauncher said: Error loading '/usr/lib64/qt5/plugins/kf5/kio/trash.so'.
And it does exist # ls -l /usr/lib64/qt5/plugins/kf5/kio/trash.so -rwxr-xr-x 1 root root 160176 Jul 16 08:02 /usr/lib64/qt5/plugins/kf5/kio/trash.so # file /usr/lib64/qt5/plugins/kf5/kio/trash.so /usr/lib64/qt5/plugins/kf5/kio/trash.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=f54a37c61b9baf204c9ee7ef09b270b0b7543e11, stripped
No, run "rpm -qfi /usr/lib64/qt5/plugins/kf5/kio/trash.so"
# rpm -qfi /usr/lib64/qt5/plugins/kf5/kio/trash.so Name : kio-core Version : 5.45.0 Release : lp150.3.3.1 Architecture: x86_64 Install Date: Sat Nov 30 22:29:33 2019 Group : System/GUI/KDE Size : 2734379 License : LGPL-2.1-or-later Signature : RSA/SHA256, Tue Jul 16 08:04:55 2019, Key ID b88b2fd43dbdc284 Source RPM : kio-5.45.0-lp150.3.3.1.src.rpm Build Date : Tue Jul 16 08:03:01 2019 Build Host : cloud131 Relocations : (not relocatable) Packager : http://bugs.opensuse.org Vendor : openSUSE URL : http://www.kde.org Summary : Network transparent access to files and data Description : This framework implements almost all the file management functions you will ever need. In fact, the KDE file manager (Dolphin) and the KDE file dialog also uses this to provide its network-enabled file management. KIO core libraries, ioslave and daemons. Distribution: openSUSE Leap 15.0 Which is what I expect. I don't see how that helps.
And trhere is also this Unable to create io-slave. klauncher said: Error loading '/usr/lib64/qt5/plugins/kf5/kio/file.so'. which means that Dolphin doesn't work, so I can't click on my movies, music document to launch them.
Same thing. # rpm -qfi /usr/lib64/qt5/plugins/kf5/kio/file.so Name : kio-core Version : 5.45.0 Release : lp150.3.3.1 Architecture: x86_64 Install Date: Sat Nov 30 22:29:33 2019 Group : System/GUI/KDE Size : 2734379 License : LGPL-2.1-or-later Signature : RSA/SHA256, Tue Jul 16 08:04:55 2019, Key ID b88b2fd43dbdc284 Source RPM : kio-5.45.0-lp150.3.3.1.src.rpm Build Date : Tue Jul 16 08:03:01 2019 Build Host : cloud131 Relocations : (not relocatable) Packager : http://bugs.opensuse.org Vendor : openSUSE URL : http://www.kde.org Summary : Network transparent access to files and data Description : This framework implements almost all the file management functions you will ever need. In fact, the KDE file manager (Dolphin) and the KDE file dialog also uses this to provide its network-enabled file management. KIO core libraries, ioslave and daemons. Distribution: openSUSE Leap 15.0
=====================================
Finally, before giving me advice that might invovle using zypper ...
# zypper refresh zypper: symbol lookup error: /usr/lib64/libproxy.so.1: undefined symbol:
_ZN9libmodman14module_manager8load_dirENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb
^^^^^^^^^^^ Please note
Hum!
You
have the wrong version of those files.
cer@Telcontar:~> rpm -qf /usr/lib64/libproxy.so.1 libproxy1-0.4.15-lp151.3.3.x86_64 cer@Telcontar:~>
# rpm -qf /usr/lib64/libproxy.so.1 libproxy1-0.4.15-lp150.2.2.x86_64
Mine has the string lp151. You should have lp150. You will need some jumping skills, like using a rescue system to update this one. Or using rpm perhaps.
You are saying I need the lp150 because I'm running leap 15.0? Well as you above I do have the the lp150. I think it is all right and the unresolved is in some other .so that either isn't there or is't of the right revision. # rpm -qf /usr/lib64/libproxy.so.1 libproxy1-0.4.15-lp150.2.2.x86_64 main:/var/log # ldd /usr/lib64/libproxy.so.1 linux-vdso.so.1 (0x00007ffec2bb5000) libmodman.so.1 => /usr/lib64/libmodman.so.1 (0x00007f8b43ba4000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8b43986000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f8b435fc000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8b433e4000) libc.so.6 => /lib64/libc.so.6 (0x00007f8b4302a000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f8b42e26000) /lib64/ld-linux-x86-64.so.2 (0x00007f8b43fca000) libm.so.6 => /lib64/libm.so.6 (0x00007f8b42aee000) # rpm -qf /usr/lib64/libmodman.so.1 libmodman1-2.0.1-20.3.x86_64 main:/var/log # strings /usr/lib64/libmodman.so.1|grep -i zn9 _ZN9libmodman14module_managerD2Ev _ZN9libmodman14module_managerD1Ev _ZN9libmodman14module_manager12load_builtinEP9mm_module _ZN9libmodman14module_manager9load_fileESsb _ZN9libmodman14module_manager8load_dirESsb -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/12/2019 19.58, Anton Aylward wrote:
On 01/12/2019 13:18, Carlos E. R. wrote:
On 01/12/2019 17.50, Anton Aylward wrote:
Yes, I now I'm late doing this and it is full of woes.
...
Finally, before giving me advice that might invovle using zypper ...
# zypper refresh zypper: symbol lookup error: /usr/lib64/libproxy.so.1: undefined symbol:
_ZN9libmodman14module_manager8load_dirENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb
^^^^^^^^^^^ Please note
I don't know what that is.
Hum!
You
have the wrong version of those files.
cer@Telcontar:~> rpm -qf /usr/lib64/libproxy.so.1 libproxy1-0.4.15-lp151.3.3.x86_64 cer@Telcontar:~>
# rpm -qf /usr/lib64/libproxy.so.1 libproxy1-0.4.15-lp150.2.2.x86_64
Mine has the string lp151. You should have lp150. You will need some jumping skills, like using a rescue system to update this one. Or using rpm perhaps.
You are saying I need the lp150 because I'm running leap 15.0?
Yes.
Well as you above I do have the the lp150.
Right.
I think it is all right and the unresolved is in some other .so that either isn't there or is't of the right revision.
Probably.
# rpm -qf /usr/lib64/libproxy.so.1 libproxy1-0.4.15-lp150.2.2.x86_64 main:/var/log # ldd /usr/lib64/libproxy.so.1 linux-vdso.so.1 (0x00007ffec2bb5000) libmodman.so.1 => /usr/lib64/libmodman.so.1 (0x00007f8b43ba4000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8b43986000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f8b435fc000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8b433e4000) libc.so.6 => /lib64/libc.so.6 (0x00007f8b4302a000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f8b42e26000) /lib64/ld-linux-x86-64.so.2 (0x00007f8b43fca000) libm.so.6 => /lib64/libm.so.6 (0x00007f8b42aee000)
# rpm -qf /usr/lib64/libmodman.so.1 libmodman1-2.0.1-20.3.x86_64
That's not from 15.0. http://download.opensuse.org/distribution/leap/15.0/repo/oss/x86_64/ [ ] libmodglue1-1.19-lp150.2.1.x86_64.rpm 21-Feb-2018 17:44 [ ] libmodman-devel-2.0.1-lp150.1.6.x86_64.rpm [ ] libmodman1-2.0.1-lp150.1.6.x86_64.rpm [ ] libmodman1-32bit-2.0.1-lp150.1.6.x86_64.rpm [ ] libmodplug-devel-0.3.7-lp150.1.3.x86_64.rpm <http://download.opensuse.org/update/leap/15.0/oss/rpms/x86_64/> No updated version. I think you should have libmodman1-2.0.1-lp150.1.6.x86_64.rpm, yet you have something else. Me, in 15.1, have: cer@Telcontar:~> rpm -q libmodman1 libmodman1-2.0.1-lp151.2.3.x86_64
main:/var/log # strings /usr/lib64/libmodman.so.1|grep -i zn9 _ZN9libmodman14module_managerD2Ev _ZN9libmodman14module_managerD1Ev _ZN9libmodman14module_manager12load_builtinEP9mm_module _ZN9libmodman14module_manager9load_fileESsb _ZN9libmodman14module_manager8load_dirESsb
That doesn't tell me anything :-? Does rpm work? Then do: rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" \ | sort | cut --fields="2-" | tee rpmlist | less -S Then refine: cat rpmlist | egrep -v "openSUSE Leap 15\.0|openSUSE_Leap_15.0" | \ less -S Until you get all rpms that do not say "15.0" in some variant. The fields should hint at what repository they came from. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 01/12/2019 14:16, Carlos E. R. wrote:
I don't know what that is.
It is how the modules reference links to other modules. In this case it is the libmodman14 module at a symbol called manager8load_dirENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb So I look in libmodule4.so and ... no its not there. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sunday, 2019-12-01 at 15:50 -0500, Anton Aylward wrote:
On 01/12/2019 14:16, Carlos E. R. wrote:
I don't know what that is.
It is how the modules reference links to other modules. In this case it is the libmodman14 module at a symbol called manager8load_dirENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb
So I look in libmodule4.so and ... no its not there.
Forget that and answer my previous question with the rpm command. I repeat:
# rpm -qf /usr/lib64/libproxy.so.1 libproxy1-0.4.15-lp150.2.2.x86_64 main:/var/log # ldd /usr/lib64/libproxy.so.1 linux-vdso.so.1 (0x00007ffec2bb5000) libmodman.so.1 => /usr/lib64/libmodman.so.1 (0x00007f8b43ba4000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8b43986000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f8b435fc000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8b433e4000) libc.so.6 => /lib64/libc.so.6 (0x00007f8b4302a000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f8b42e26000) /lib64/ld-linux-x86-64.so.2 (0x00007f8b43fca000) libm.so.6 => /lib64/libm.so.6 (0x00007f8b42aee000)
# rpm -qf /usr/lib64/libmodman.so.1 libmodman1-2.0.1-20.3.x86_64
That's not from 15.0. http://download.opensuse.org/distribution/leap/15.0/repo/oss/x86_64/ [ ] libmodglue1-1.19-lp150.2.1.x86_64.rpm 21-Feb-2018 17:44 [ ] libmodman-devel-2.0.1-lp150.1.6.x86_64.rpm [ ] libmodman1-2.0.1-lp150.1.6.x86_64.rpm [ ] libmodman1-32bit-2.0.1-lp150.1.6.x86_64.rpm [ ] libmodplug-devel-0.3.7-lp150.1.3.x86_64.rpm <http://download.opensuse.org/update/leap/15.0/oss/rpms/x86_64/> No updated version. I think you should have libmodman1-2.0.1-lp150.1.6.x86_64.rpm, yet you have something else. Me, in 15.1, have: cer@Telcontar:~> rpm -q libmodman1 libmodman1-2.0.1-lp151.2.3.x86_64
main:/var/log # strings /usr/lib64/libmodman.so.1|grep -i zn9 _ZN9libmodman14module_managerD2Ev _ZN9libmodman14module_managerD1Ev _ZN9libmodman14module_manager12load_builtinEP9mm_module _ZN9libmodman14module_manager9load_fileESsb _ZN9libmodman14module_manager8load_dirESsb
That doesn't tell me anything :-? Does rpm work? Then do: rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" \ | sort | cut --fields="2-" | tee rpmlist | less -S Then refine: cat rpmlist | egrep -v "openSUSE Leap 15\.0|openSUSE_Leap_15.0" | \ less -S Until you get all rpms that do not say "15.0" in some variant. The fields should hint at what repository they came from. -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/12/2019 16:13, Carlos E. R. wrote:
On Sunday, 2019-12-01 at 15:50 -0500, Anton Aylward wrote:
Does rpm work? Then do:
rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" \ | sort | cut --fields="2-" | tee rpmlist | less -S
Then refine:
cat rpmlist | egrep -v "openSUSE Leap 15\.0|openSUSE_Leap_15.0" | \ less -S
Until you get all rpms that do not say "15.0" in some variant. The fields should hint at what repository they came from.
There are 1502 entries in that. But some are like this and I'm not sure they should be in the list Sat Nov 30 2019 Thu Nov 21 2019 thunar 1.8.11-lp150.150.1 x86_64 obs://build.opensuse.org/X11 (none) == X11:xfce / Leap_15.0 Sat Nov 30 2019 Thu Apr 26 2018 unrar 5.6.1-lp150.1.1 x86_64 openSUSEhttps://bugs.opensuse.org == openSUSE:Leap:15.0:NonFree (none) Then there are the obvious ones Sat Nov 30 2019 Wed Jun 14 2017 libKF5Holidays5 17.04.2-1.1 x86_64 openSUSE http://bugs.opensuse.org == openSUSE Leap 42.3 (none) but without a working zypper I can't see what to do about them
-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/12/2019 01.40, Anton Aylward wrote:
On 01/12/2019 16:13, Carlos E. R. wrote:
On Sunday, 2019-12-01 at 15:50 -0500, Anton Aylward wrote:
Does rpm work? Then do:
rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" \ | sort | cut --fields="2-" | tee rpmlist | less -S
Then refine:
cat rpmlist | egrep -v "openSUSE Leap 15\.0|openSUSE_Leap_15.0" | \ less -S
Until you get all rpms that do not say "15.0" in some variant. The fields should hint at what repository they came from.
There are 1502 entries in that.
But some are like this and I'm not sure they should be in the list
Sat Nov 30 2019 Thu Nov 21 2019 thunar 1.8.11-lp150.150.1 x86_64 obs://build.opensuse.org/X11 (none) == X11:xfce / Leap_15.0
As I said, refine: cat rpmlist | egrep -v \ "openSUSE Leap 15\.0|openSUSE_Leap_15.0|Leap_15.0" | \ less -S
Sat Nov 30 2019 Thu Apr 26 2018 unrar 5.6.1-lp150.1.1 x86_64 openSUSEhttps://bugs.opensuse.org == openSUSE:Leap:15.0:NonFree (none)
Continue refining: cat rpmlist | egrep -v \ "openSUSE Leap 15\.0|openSUSE_Leap_15.0|Leap_15.0|Leap\:15.0" | \ less -S
Then there are the obvious ones
Sat Nov 30 2019 Wed Jun 14 2017 libKF5Holidays5 17.04.2-1.1 x86_64 openSUSE http://bugs.opensuse.org == openSUSE Leap 42.3 (none)
but without a working zypper I can't see what to do about them
Download with any browser that works to a directory and upgrade with rpm command. At least those that seem candidates for zypper. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeRhkQAKCRC1MxgcbY1H 1VJKAKCKnhU7Or3I1xYFvJO/ufAcNnu4SACeIU23AMCLYaTAwg0dq9z0qNG/rPg= =NXD2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/12/2019 16:13, Carlos E. R. wrote:
Until you get all rpms that do not say "15.0" in some variant. The fields should hint at what repository they came from.
In all that is # cat rpmlist | egrep -v "openSUSE Leap 15\.0|Leap_15\.0|Leap\:15" | grep modman Sat Mar 17 2018 Tue May 09 2017 libmodman1 2.0.1-20.3 x86_64 openSUSE http://bugs.opensuse.org == openSUSE Leap 42.3 (none) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sunday, 2019-12-01 at 15:50 -0500, Anton Aylward wrote:
On 01/12/2019 14:16, Carlos E. R. wrote:
I don't know what that is.
It is how the modules reference links to other modules. In this case it is the libmodman14 module at a symbol called manager8load_dirENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb
So I look in libmodule4.so and ... no its not there.
To be clear: you have packages from 42.3 in your 15.0 install. This one, at least:
# rpm -qf /usr/lib64/libmodman.so.1 libmodman1-2.0.1-20.3.x86_64
I posted an hour ago how to find out with rpm the list of packages that are not from 15.0. You have to find them all and update them. With rpm command. Or at least, those that zypper needs. Then you have to verify your zypper repo list. zypper lr --details It is possible some are not for 15.0 -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. composed on 2019-12-01 22:23 (UTC+0100):
not from 15.0. You have to find them all and update them. With rpm command.
rpm -qa | grep -v lp15 returns only packages not from leap 15
Or at least, those that zypper needs.
http://download.opensuse.org/distribution/leap/15.0/repo/oss/x86_64/libmodma... -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/12/2019 22.51, Felix Miata wrote:
Carlos E. R. composed on 2019-12-01 22:23 (UTC+0100):
not from 15.0. You have to find them all and update them. With rpm command.
rpm -qa | grep -v lp15
returns only packages not from leap 15
My command I posted is quite more complete ;-)
Or at least, those that zypper needs.
http://download.opensuse.org/distribution/leap/15.0/repo/oss/x86_64/libmodma... That
one for starters. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E. R. composed on 2019-12-01 22:56 (UTC+0100):
Felix Miata wrote:
Carlos E. R. composed on 2019-12-01 22:23 (UTC+0100):
not from 15.0. You have to find them all and update them. With rpm command.
rpm -qa | grep -v lp15
returns only packages not from leap 15
My command I posted is quite more complete ;-)
???
Or at least, those that zypper needs.
http://download.opensuse.org/distribution/leap/15.0/repo/oss/x86_64/libmodma...
That
one for starters.
http://download.opensuse.org/distribution/leap/15.0/repo/oss/x86_64/libproxy... ? I think only these three depend on each other: http://download.opensuse.org/update/leap/15.0/oss/rpms/x86_64/libsolv-tools-... http://download.opensuse.org/update/leap/15.0/oss/rpms/x86_64/libzypp-17.15.... http://download.opensuse.org/update/leap/15.0/oss/rpms/x86_64/zypper-1.14.32... rpm -e libzypp fails on those and 5 yast*/libyui*pg* packages only. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/12/2019 23.33, Felix Miata wrote:
Carlos E. R. composed on 2019-12-01 22:56 (UTC+0100):
Felix Miata wrote:
Carlos E. R. composed on 2019-12-01 22:23 (UTC+0100):
not from 15.0. You have to find them all and update them. With rpm command.
rpm -qa | grep -v lp15
returns only packages not from leap 15
My command I posted is quite more complete ;-)
???
rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" \ | sort | cut --fields="2-" | tee rpmlist | less -S - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeRiFQAKCRC1MxgcbY1H 1ZOUAJ0TqFapYlMo3HzDFdZl3lz8bfikmgCeIN1NDZzJ/ev2MB+aBVKOkB/vWVA= =F5lV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/12/2019 16:56, Carlos E. R. wrote:
On 01/12/2019 22.51, Felix Miata wrote:
Carlos E. R. composed on 2019-12-01 22:23 (UTC+0100):
not from 15.0. You have to find them all and update them. With rpm command.
rpm -qa | grep -v lp15
returns only packages not from leap 15
My command I posted is quite more complete ;-)
Or at least, those that zypper needs.
http://download.opensuse.org/distribution/leap/15.0/repo/oss/x86_64/libmodma...
That
one for starters.
rpm -qa | grep libmodman libmodman1-2.0.1-20.3.x86_64 # rpm -Uv libmodman1-2.0.1-lp150.1.6.x86_64.rpm Preparing packages... package libmodman1-2.0.1-20.3.x86_64 (which is newer than libmodman1-2.0.1-lp150.1.6.x86_64) is already installed I say again, I think the 42.3 packages are higher numbered that the 15.0 ones. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/12/2019 02.05, Anton Aylward wrote:
On 01/12/2019 16:56, Carlos E. R. wrote:
On 01/12/2019 22.51, Felix Miata wrote:
Carlos E. R. composed on 2019-12-01 22:23 (UTC+0100):
not from 15.0. You have to find them all and update them. With rpm command.
rpm -qa | grep -v lp15
returns only packages not from leap 15
My command I posted is quite more complete ;-)
Or at least, those that zypper needs.
http://download.opensuse.org/distribution/leap/15.0/repo/oss/x86_64/libmodma...
That
one for starters.
rpm -qa | grep libmodman libmodman1-2.0.1-20.3.x86_64
# rpm -Uv libmodman1-2.0.1-lp150.1.6.x86_64.rpm Preparing packages... package libmodman1-2.0.1-20.3.x86_64 (which is newer than libmodman1-2.0.1-lp150.1.6.x86_64) is already installed
I say again, I think the 42.3 packages are higher numbered that the 15.0 ones.
And I say you use the foce, Luke... -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 01/12/2019 16:51, Felix Miata wrote:
Carlos E. R. composed on 2019-12-01 22:23 (UTC+0100):
not from 15.0. You have to find them all and update them. With rpm command.
rpm -qa | grep -v lp15
returns only packages not from leap 15
# rpm -qa | grep -v lp15| wc -l 1465
Or at least, those that zypper needs.
And a thousand more.
http://download.opensuse.org/distribution/leap/15.0/repo/oss/x86_64/libmodma...
Yes, I ftp'd that down and # rpm -Uv libmodman1-2.0.1-lp150.1.6.x86_64.rpm Preparing packages... package libmodman1-2.0.1-20.3.x86_64 (which is newer than libmodman1-2.0.1-lp150.1.6.x86_64) is already installed # rpm -qa | grep libmodman libmodman1-2.0.1-20.3.x86_64 I think there is a problem with the comparative 42.3 and 15.0 package numbering. Wasn't there a post about that a while ago? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/12/2019 02.03, Anton Aylward wrote:
On 01/12/2019 16:51, Felix Miata wrote:
Carlos E. R. composed on 2019-12-01 22:23 (UTC+0100):
not from 15.0. You have to find them all and update them. With rpm command.
rpm -qa | grep -v lp15
returns only packages not from leap 15
# rpm -qa | grep -v lp15| wc -l 1465
Or at least, those that zypper needs.
And a thousand more.
http://download.opensuse.org/distribution/leap/15.0/repo/oss/x86_64/libmodma...
Yes, I ftp'd that down and
# rpm -Uv libmodman1-2.0.1-lp150.1.6.x86_64.rpm Preparing packages... package libmodman1-2.0.1-20.3.x86_64 (which is newer than libmodman1-2.0.1-lp150.1.6.x86_64) is already installed
Use the force, Luke... David Haller told you the incantation to use. His second post.
# rpm -qa | grep libmodman libmodman1-2.0.1-20.3.x86_64
I think there is a problem with the comparative 42.3 and 15.0 package numbering. Wasn't there a post about that a while ago?
The problem is, I guess, that one of your repos is pointing at the wrong URL. grep "baseurl" /etc/zypp/repos.d/*.repo -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 01/12/2019 20:08, Carlos E. R. wrote:
On 02/12/2019 02.03, Anton Aylward wrote:
On 01/12/2019 16:51, Felix Miata wrote:
Carlos E. R. composed on 2019-12-01 22:23 (UTC+0100):
not from 15.0. You have to find them all and update them. With rpm command.
rpm -qa | grep -v lp15
returns only packages not from leap 15
# rpm -qa | grep -v lp15| wc -l 1465
Or at least, those that zypper needs.
And a thousand more.
http://download.opensuse.org/distribution/leap/15.0/repo/oss/x86_64/libmodma...
Yes, I ftp'd that down and
# rpm -Uv libmodman1-2.0.1-lp150.1.6.x86_64.rpm Preparing packages... package libmodman1-2.0.1-20.3.x86_64 (which is newer than libmodman1-2.0.1-lp150.1.6.x86_64) is already installed
Use the force, Luke... David Haller told you the incantation to use. His second post.
# rpm -qa | grep libmodman libmodman1-2.0.1-20.3.x86_64
I think there is a problem with the comparative 42.3 and 15.0 package numbering. Wasn't there a post about that a while ago?
The problem is, I guess, that one of your repos is pointing at the wrong URL.
grep "baseurl" /etc/zypp/repos.d/*.repo
# grep "baseurl" /etc/zypp/repos.d/*.repo | egrep -v "15\.0" /etc/zypp/repos.d/Kernel_Stable.repo:baseurl=http://download.opensuse.org/repositories/Kernel:/stable/standard/ Disabled /etc/zypp/repos.d/Lightzone.repo:baseurl=http://download.opensuse.org/repositories/home:/ktgw0316:/LightZone/openSUSE... Disabled /etc/zypp/repos.d/home:darix:darktable:master.repo:baseurl=http://download.opensuse.org/repositories/home:/darix:/darktable:/master/ope... Disabled /etc/zypp/repos.d/http-download.opensuse.org-2f1b016a.repo:baseurl=http://download.opensuse.org/repositories/home:/napobear/openSUSE_Leap_15.1/ Disabled. I did a global edit of the repos 42.3 -> 15.0 These were the exceptions. The kernel_stable is os-revision independent. The other have no 15.0 version. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/12/2019 02.28, Anton Aylward wrote:
On 01/12/2019 20:08, Carlos E. R. wrote:
The problem is, I guess, that one of your repos is pointing at the wrong URL.
grep "baseurl" /etc/zypp/repos.d/*.repo
# grep "baseurl" /etc/zypp/repos.d/*.repo | egrep -v "15\.0" /etc/zypp/repos.d/Kernel_Stable.repo:baseurl=http://download.opensuse.org/repositories/Kernel:/stable/standard/
Disabled
/etc/zypp/repos.d/Lightzone.repo:baseurl=http://download.opensuse.org/repositories/home:/ktgw0316:/LightZone/openSUSE...
Disabled
/etc/zypp/repos.d/home:darix:darktable:master.repo:baseurl=http://download.opensuse.org/repositories/home:/darix:/darktable:/master/ope...
Disabled
/etc/zypp/repos.d/http-download.opensuse.org-2f1b016a.repo:baseurl=http://download.opensuse.org/repositories/home:/napobear/openSUSE_Leap_15.1/
Disabled.
I did a global edit of the repos 42.3 -> 15.0 These were the exceptions. The kernel_stable is os-revision independent. The other have no 15.0 version.
Ok. Then the other explanation is that you used "zypper up" instead of "zypper dup" for the 42.3 to 15.0 procedure... -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E.R. composed on 2019-12-02 02:31 (UTC+0100):
Then the other explanation is that you used "zypper up" instead of "zypper dup" for the 42.3 to 15.0 procedure...
The following command would show if that happened: # grep zypper /var/log/zypp/history | grep 2019-12-01 Actual result here: 2019-12-01 17:37:24|command|myhost|'zypper' '-v' 'in' '--download-in-advance' 'zypper' 'libzypp' 'libsolv-tools' 'rpm' 'libproxy1' 'libmodman1' 'openSUSE-release'| 2019-12-01 17:37:33|install|zypper|1.14.32-lp150.2.19.1|x86_64|myhost|Update|0e8b78bad9f4a7fae26ab193398d823826acf3ab5c94ffac02cce44d71b0afc4| 2019-12-01 17:37:58|command|myhost|'zypper' '-v' 'in' '--download-in-advance' 'device-mapper' 'dmraid' 'glibc' 'multipath-tools' 'mdadm' 'systemd' 'udev'| 2019-12-01 17:38:42|command|myhost|'zypper' '-v' 'up'| 2019-12-01 17:43:53|install|zypper-log|1.14.32-lp150.2.19.1|noarch||Update|eb97add036516ba75168bdc9252def9ef0afe2261562420f3c7478a1c9527c07| 2019-12-01 19:02:01|command|myhost|'zypper' '-v' 'in' 'kernel-default'| Above is what I actually did today, but it wasn't from 42.3. The first two commands are in a script I run before updating or upgrading. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/12/2019 16:23, Carlos E. R. wrote:
Then you have to verify your zypper repo list.
zypper lr --details
It is possible some are not for 15.0
ROTFLMAO, or possibly crying with anguish # zypper refresh zypper: symbol lookup error: /usr/lib64/libproxy.so.1: undefined symbol: _ZN9libmodman14module_manager8load_dirENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb # zypper up zypper: symbol lookup error: /usr/lib64/libproxy.so.1: undefined symbol: _ZN9libmodman14module_manager8load_dirENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb ... once I get zypper working ... -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/12/2019 01.53, Anton Aylward wrote:
On 01/12/2019 16:23, Carlos E. R. wrote:
Then you have to verify your zypper repo list.
zypper lr --details
It is possible some are not for 15.0
ROTFLMAO, or possibly crying with anguish
# zypper refresh zypper: symbol lookup error: /usr/lib64/libproxy.so.1: undefined symbol:
_ZN9libmodman14module_manager8load_dirENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb Means,
I think, that libproxy needs something else that has the wrong package version. Possibly "libmodman1", so upgrade that one with rpm. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 01/12/2019 20:02, Carlos E. R. wrote:
On 02/12/2019 01.53, Anton Aylward wrote:
On 01/12/2019 16:23, Carlos E. R. wrote:
Then you have to verify your zypper repo list.
zypper lr --details
It is possible some are not for 15.0
ROTFLMAO, or possibly crying with anguish
# zypper refresh zypper: symbol lookup error: /usr/lib64/libproxy.so.1: undefined symbol:
_ZN9libmodman14module_manager8load_dirENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb
Means,
I think, that libproxy needs something else that has the wrong package version.
Possibly "libmodman1", so upgrade that one with rpm.
Yes, figured that out, tried it and the rpm -U and the the rpm -I complain. As i say, I think there is a problem that the 42.3 packages are higher numbered than the 15.0 ones. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/12/2019 02.08, Anton Aylward wrote:
On 01/12/2019 20:02, Carlos E. R. wrote:
On 02/12/2019 01.53, Anton Aylward wrote:
On 01/12/2019 16:23, Carlos E. R. wrote:
Possibly "libmodman1", so upgrade that one with rpm.
Yes, figured that out, tried it and the rpm -U and the the rpm -I complain.
As i say, I think there is a problem that the 42.3 packages are higher numbered than the 15.0 ones.
Irrelevant :-D - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeRkcAAKCRC1MxgcbY1H 1RFgAKCZYeKwCzsiWn3rqM2++AmYpHir2gCgmIYoCALOZmkmYx4MnTqjvEIlT/8= =+JfL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/12/2019 20:10, Carlos E. R. wrote:
As i say, I think there is a problem that the 42.3 packages are higher numbered than the 15.0 ones.
Irrelevant :-D
Well that would certain explain why the RPM fails to install a supposedly later package. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/12/2019 02.13, Anton Aylward wrote:
On 01/12/2019 20:10, Carlos E. R. wrote:
As i say, I think there is a problem that the 42.3 packages are higher numbered than the 15.0 ones.
Irrelevant :-D
Well that would certain explain why the RPM fails to install a supposedly later package.
Nope. Supposedly you did the initial upgrade with "zypper dup", wich ignores version downgrades and does it nevertheless. And with "zypper up" I told you to use the force, several times, and hours ago David Haller told you the same thing :-D Did you perchance do the 42.3 to 15.0 upgrade with zypper up? That fails... - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeRnMwAKCRC1MxgcbY1H 1U/DAJ43DBTDbm52E/6+FFjZ5ZkwU0kL9QCdFKSWPVS0HSJ2gvXDGSL0sfxeWNM= =L0c7 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/12/2019 20:21, Carlos E. R. wrote:
Did you perchance do the 42.3 to 15.0 upgrade with zypper up? That fails...
Ah, there you have it. That was my mistake. Running a "dup" now. Odd, some things like TB/FF are regressing... -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2019-12-01 a las 21:02 -0500, Anton Aylward escribió:
On 01/12/2019 20:21, Carlos E. R. wrote:
Did you perchance do the 42.3 to 15.0 upgrade with zypper up? That fails...
Ah, there you have it. That was my mistake. Running a "dup" now.
Good, you got zypper working. Maybe you should upgrade zypper itself first.
Odd, some things like TB/FF are regressing...
Are your update repos active? It is possible that the "updated" versions of 42.3 are newer that the ones in oss repo of 15.0, yes. - -- Cheers Carlos E. R. (from openSUSE 15.1 (Legolas)) -----BEGIN PGP SIGNATURE----- iHIEARECADIWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeRyWxQccm9iaW4ubGlz dGFzQGdteC5lcwAKCRC1MxgcbY1H1eqcAJ9ayRoQUs2ajIx/9jJdvYSzeWKDRQCf eGEx8A4fE5xdRCX3O7Ft8WKzlWU= =p/V4 -----END PGP SIGNATURE-----
On 12/01/2019 08:02 PM, Anton Aylward wrote:
On 01/12/2019 20:21, Carlos E. R. wrote:
Did you perchance do the 42.3 to 15.0 upgrade with zypper up? That fails...
Ah, there you have it. That was my mistake. Running a "dup" now.
Odd, some things like TB/FF are regressing...
After having done the 42.3->15.0 a few weeks ago, the only issue that got me were a few packages switched repos. So if you have any lingering issues after your zypper dup completes, check where any errant package comes from. For me the new rule is disable all repos except OSS/Update, Nvidia, KDE3 and update allowing vendor change and then re-enable the other repos and zypper up, then switch packages back to packman, etc... Also, I want your feedback on whether you notice font rendering problems on 15.0 compared to 42.3. My fonts (same from 42.3) render smaller on 15.0 than they do on 42.3. Main package difference is freetype 2.6 on 42.3 and freetype 2.9 on 15.0. I patch both the same to enable original LCD hinting - which itself is fine, but the basic font scaling/rendering seems changed somehow. Fonts are smaller with less kerning. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/12/2019 02:19, David C. Rankin wrote:
On 12/01/2019 08:02 PM, Anton Aylward wrote:
On 01/12/2019 20:21, Carlos E. R. wrote:
Did you perchance do the 42.3 to 15.0 upgrade with zypper up? That fails...
Ah, there you have it. That was my mistake. Running a "dup" now.
Odd, some things like TB/FF are regressing...
After having done the 42.3->15.0 a few weeks ago, the only issue that got me were a few packages switched repos. So if you have any lingering issues after your zypper dup completes, check where any errant package comes from.
OK. Overnight I ran the "dup". Nearly 2,000 changes. As I said, regressing. The initial 'Up" gave men TB 68.2.2 The "dup" gave me MozillaThunderbird-68.2.1 I now get # zypper up MozillaThunderbird There is an update candidate for 'MozillaThunderbird' from vendor 'openSUSE', while the current vendor is 'obs://build.opensuse.org/mozilla'. Use 'zypper install MozillaThunderbird-68.2.1-lp150.3.54.1.x86_64' to install this candidate. There is an update candidate for 'MozillaThunderbird', but it comes from a repository with a lower priority. Use 'zypper install MozillaThunderbird-68.2.1-lp150.3.54.1.x86_64' to install this candidate. So where did 68.2.2 come from in my initial "up"? After running the "dup" I try running a "up" and a "patch" and find there are quite a number of regressions.
Also, I want your feedback on whether you notice font rendering problems on 15.0 compared to 42.3. My fonts (same from 42.3) render smaller on 15.0 than they do on 42.3. Main package difference is freetype 2.6 on 42.3 and freetype 2.9 on 15.0. I patch both the same to enable original LCD hinting - which itself is fine, but the basic font scaling/rendering seems changed somehow. Fonts are smaller with less kerning.
I haven't noticed any but then I'm not that critical about fonts. So long as I can read it, I get by.
-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/12/2019 09:10, Anton Aylward wrote:
I haven't noticed any but then I'm not that critical about fonts. So long as I can read it, I get by.
Now, following the "dup" Dolphin has stopped working. navigation by click on folders isn't working, preview isn't working. No update candidate -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/12/2019 09:10, Anton Aylward wrote:
I haven't noticed any but then I'm not that critical about fonts. So long as I can read it, I get by.
Now, following the "dup" Dolphin has stopped working. navigation by click on folders isn't working, preview isn't working. So I shut it down and restarted. Now I get no display and the error message Unable to create io-slave. klauncher said: Error loading '/usr/lib64/qt5/plugins/kf5/kio/file.so'. Back to that again. # ls -l /usr/lib64/qt5/plugins/kf5/kio/file.so -rwxr-xr-x 1 root root 119176 Nov 7 14:22 /usr/lib64/qt5/plugins/kf5/kio/file.so # rpm -qf /usr/lib64/qt5/plugins/kf5/kio/file.so kio-core-5.64.0-lp150.276.1.x86_64 The curious thing is that when I (manually) start dolphin as root it seems to work fine. How is this a permissions problem? The libraries are universality readable and executable. All the directories leading there are universally readable and searchable. No update candidates for dolphin or kio-core Oh, Monday morning blues .... -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward composed on 2019-12-02 10:00 (UTC-0500):
Now, following the "dup" Dolphin has stopped working. navigation by click on folders isn't working, preview isn't working.
So I shut it down and restarted. Now I get no display and the error message
Unable to create io-slave. klauncher said: Error loading '/usr/lib64/qt5/plugins/kf5/kio/file.so'.
Back to that again.
# ls -l /usr/lib64/qt5/plugins/kf5/kio/file.so -rwxr-xr-x 1 root root 119176 Nov 7 14:22 /usr/lib64/qt5/plugins/kf5/kio/file.so # rpm -qf /usr/lib64/qt5/plugins/kf5/kio/file.so kio-core-5.64.0-lp150.276.1.x86_64
The curious thing is that when I (manually) start dolphin as root it seems to work fine. How is this a permissions problem? The libraries are universality readable and executable. All the directories leading there are universally readable and searchable.
No update candidates for dolphin or kio-core
See if dup erred and will offer to fix by running: zypper ve -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/12/2019 10:35, Felix Miata wrote:
Anton Aylward composed on 2019-12-02 10:00 (UTC-0500):
Now, following the "dup" Dolphin has stopped working. navigation by click on folders isn't working, preview isn't working.
So I shut it down and restarted. Now I get no display and the error message
Unable to create io-slave. klauncher said: Error loading '/usr/lib64/qt5/plugins/kf5/kio/file.so'.
Back to that again.
# ls -l /usr/lib64/qt5/plugins/kf5/kio/file.so -rwxr-xr-x 1 root root 119176 Nov 7 14:22 /usr/lib64/qt5/plugins/kf5/kio/file.so # rpm -qf /usr/lib64/qt5/plugins/kf5/kio/file.so kio-core-5.64.0-lp150.276.1.x86_64
The curious thing is that when I (manually) start dolphin as root it seems to work fine. How is this a permissions problem? The libraries are universality readable and executable. All the directories leading there are universally readable and searchable.
No update candidates for dolphin or kio-core
See if dup erred and will offer to fix by running:
zypper ve
I get this: # zypper ve Loading repository data... Reading installed packages... Dependencies of all installed packages are satisfied. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/12/2019 17.11, Anton Aylward wrote:
On 02/12/2019 10:35, Felix Miata wrote:
Anton Aylward composed on 2019-12-02 10:00 (UTC-0500):
Now, following the "dup" Dolphin has stopped working. navigation by click on folders isn't working, preview isn't working.
So I shut it down and restarted. Now I get no display and the error message
Unable to create io-slave. klauncher said: Error loading '/usr/lib64/qt5/plugins/kf5/kio/file.so'.
Back to that again.
# ls -l /usr/lib64/qt5/plugins/kf5/kio/file.so -rwxr-xr-x 1 root root 119176 Nov 7 14:22 /usr/lib64/qt5/plugins/kf5/kio/file.so # rpm -qf /usr/lib64/qt5/plugins/kf5/kio/file.so kio-core-5.64.0-lp150.276.1.x86_64
The curious thing is that when I (manually) start dolphin as root it seems to work fine. How is this a permissions problem? The libraries are universality readable and executable. All the directories leading there are universally readable and searchable.
Somebody recently had a similar problem. Who and where...:-? Check perchance if you have got kde/plasma files from packman, and if so, switch them to oss.
No update candidates for dolphin or kio-core
See if dup erred and will offer to fix by running:
zypper ve
I get this:
# zypper ve Loading repository data... Reading installed packages...
Dependencies of all installed packages are satisfied.
Please do: zypper lr --details > somefile.txt Then attach (not paste) somefile.txt to the mail reply. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeVjiQAKCRC1MxgcbY1H 1SoRAJ45jzqgsIUVe44RylrMgK/JX1N+mgCeOsrQDE1alZB9PyqZ8RV1gkyFUBg= =p8dk -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/02/2019 01:18 PM, Carlos E. R. wrote:
Somebody recently had a similar problem. Who and where...:-?
Check perchance if you have got kde/plasma files from packman, and if so, switch them to oss.
That was me! zypper dup 42.3 -> 15.0 pulled Qt3 from packman instead of KDE3 which broke the kde3 styles in kde3. The mozilla 68.2.2 and 2.1 issue is due to the up (apparently having allow-vendor-change pulling the latest from the mozilla repo while dup (unless you specified --allow-vendor-change) would limit to pulling from where your current package is installed from (theoretically). -- David C. Rankin, J.D.,P.E.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/12/2019 01.13, David C. Rankin wrote:
On 12/02/2019 01:18 PM, Carlos E. R. wrote:
Somebody recently had a similar problem. Who and where...:-?
Check perchance if you have got kde/plasma files from packman, and if so, switch them to oss.
That was me!
LOL, indeed! - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeXQBwAKCRC1MxgcbY1H 1SqfAKCLRwFpW8+d8UkdTYD0JKODk5g0owCfTcHxo1R55l65v+x1Z9MzH1Uhwd0= =jhAy -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/12/2019 14:18, Carlos E. R. wrote:
On 02/12/2019 17.11, Anton Aylward wrote:
On 02/12/2019 10:35, Felix Miata wrote:
Anton Aylward composed on 2019-12-02 10:00 (UTC-0500):
Now, following the "dup" Dolphin has stopped working. navigation by click on folders isn't working, preview isn't working.
So I shut it down and restarted. Now I get no display and the error message
Unable to create io-slave. klauncher said: Error loading '/usr/lib64/qt5/plugins/kf5/kio/file.so'.
Back to that again.
# ls -l /usr/lib64/qt5/plugins/kf5/kio/file.so -rwxr-xr-x 1 root root 119176 Nov 7 14:22 /usr/lib64/qt5/plugins/kf5/kio/file.so # rpm -qf /usr/lib64/qt5/plugins/kf5/kio/file.so kio-core-5.64.0-lp150.276.1.x86_64
The curious thing is that when I (manually) start dolphin as root it seems to work fine. How is this a permissions problem? The libraries are universality readable and executable. All the directories leading there are universally readable and searchable.
Somebody recently had a similar problem. Who and where...:-?
Check perchance if you have got kde/plasma files from packman, and if so, switch them to oss.
They are from obs://build.opensuse.org/KDE But so what if they are from a different repository? it works fine if invoked as ROOT, it doesn't work if invoked as a regular user. if it were a 'wrong repository' issue then it would behave the same way no matter who invoked it. As user anton: anton@main:~/tmp> dolphin kf5.ki18n: Trying to convert empty KLocalizedString to QString. org.kde.dolphin: Ignore KIO url: QUrl("timeline:/today") org.kde.dolphin: Ignore KIO url: QUrl("timeline:/yesterday") org.kde.dolphin: Ignore KIO url: QUrl("search:/documents") org.kde.dolphin: Ignore KIO url: QUrl("search:/images") org.kde.dolphin: Ignore KIO url: QUrl("search:/audio") org.kde.dolphin: Ignore KIO url: QUrl("search:/videos") qt.accessibility.core: Cannot create accessible child interface for object: PlacesView(0x557c5c3f7d80) index: 40 kf5.kio.core: couldn't create slave: "klauncher said: Error loading '/usr/lib64/qt5/plugins/kf5/kio/tags.so'." kf5.kio.core: "Unable to create io-slave. klauncher said: Error loading '/usr/lib64/qt5/plugins/kf5/kio/tags.so'." kf5.kio.core: "Unable to create io-slave. klauncher said: Error loading '/usr/lib64/qt5/plugins/kf5/kio/tags.so'." kf5.kio.core: couldn't create slave: "klauncher said: Error loading '/usr/lib64/qt5/plugins/kf5/kio/file.so'." kf5.kio.core: couldn't create slave: "klauncher said: Error loading '/usr/lib64/qt5/plugins/kf5/kio/trash.so'." kf5.kio.core: "Unable to create io-slave. klauncher said: Error loading '/usr/lib64/qt5/plugins/kf5/kio/trash.so'." kf5.kio.core: couldn't create slave: "klauncher said: Error loading '/usr/lib64/qt5/plugins/kf5/kio/file.so'." kf5.kio.core: couldn't create slave: "klauncher said: Error loading '/usr/lib64/qt5/plugins/kf5/kio/file.so'." As user ROOT: main:/tmp # dolphin QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' org.kde.dolphin: Ignore KIO url: QUrl("timeline:/today") org.kde.dolphin: Ignore KIO url: QUrl("timeline:/yesterday") org.kde.dolphin: Ignore KIO url: QUrl("search:/documents") org.kde.dolphin: Ignore KIO url: QUrl("search:/images") org.kde.dolphin: Ignore KIO url: QUrl("search:/audio") org.kde.dolphin: Ignore KIO url: QUrl("search:/videos") qt.accessibility.core: Cannot create accessible child interface for object: PlacesView(0x564c836b7af0) index: 41 QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
No update candidates for dolphin or kio-core
See if dup erred and will offer to fix by running:
zypper ve
I get this:
# zypper ve Loading repository data... Reading installed packages...
Dependencies of all installed packages are satisfied.
Please do:
zypper lr --details > somefile.txt
Then attach (not paste) somefile.txt to the mail reply.
URL: https://susepaste.org/14128019 -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/12/2019 02.16, Anton Aylward wrote:
On 02/12/2019 14:18, Carlos E. R. wrote:
On 02/12/2019 17.11, Anton Aylward wrote:
On 02/12/2019 10:35, Felix Miata wrote:
Anton Aylward composed on 2019-12-02 10:00 (UTC-0500):
Now, following the "dup" Dolphin has stopped working. navigation by click on folders isn't working, preview isn't working.
So I shut it down and restarted. Now I get no display and the error message
Unable to create io-slave. klauncher said: Error loading '/usr/lib64/qt5/plugins/kf5/kio/file.so'.
Back to that again.
# ls -l /usr/lib64/qt5/plugins/kf5/kio/file.so -rwxr-xr-x 1 root root 119176 Nov 7 14:22 /usr/lib64/qt5/plugins/kf5/kio/file.so # rpm -qf /usr/lib64/qt5/plugins/kf5/kio/file.so kio-core-5.64.0-lp150.276.1.x86_64
The curious thing is that when I (manually) start dolphin as root it seems to work fine. How is this a permissions problem? The libraries are universality readable and executable. All the directories leading there are universally readable and searchable.
Somebody recently had a similar problem. Who and where...:-?
Check perchance if you have got kde/plasma files from packman, and if so, switch them to oss.
They are from obs://build.opensuse.org/KDE
But so what if they are from a different repository?
Some times bad things happen.
it works fine if invoked as ROOT, it doesn't work if invoked as a regular user.
if it were a 'wrong repository' issue then it would behave the same way no matter who invoked it.
I wouldn't be that sure. It can be built with different options. ...
Please do:
zypper lr --details > somefile.txt
Then attach (not paste) somefile.txt to the mail reply.
Try again, without wrapping the lines. I prefer you attach the file - precisely to avoid that line wrap. I can bet already that the repo list is the cause of your problems, though... - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeXRfQAKCRC1MxgcbY1H 1SxaAKCLo1t/P5RHNS/oAZzZ3sNbwXFnJQCeJDZeaDLLn3GNVZ8w6oZEboDpvAM= =SGij -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/12/2019 22:07, Carlos E. R. wrote:
I can bet already that the repo list is the cause of your problems, though...
Nope. The messaging and timing in the overall thread got out of order. My problem was I did do a 'zypper dup' on the 42.3 BEFORE changing the repos to point to 15.0 BUT did only a 'zypper up' AFTER that change. I've since done the 'zypper dup' and it has cleared up many problems, though created others. I'll discuss those in the morning, but they have nothing whatsoever to do with the repositories per se and seem to be 15.0 application differences and configuration differences (eg: sddm rather than xdm) issues. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward composed on 2019-12-02 20:16 (UTC-0500):
Carlos E. R. wrote:
Please do:
zypper lr --details > somefile.txt
Then attach (not paste) somefile.txt to the mail reply.
One of the reasons for using susepaste is to provide a chance of avoiding the line wrapping that makes it difficult to make sense of the output. In your paste, each line is doubly wrapped, compounding the difficulty, on top of having an insane number of repositories. Redirecting to file avoids the wrapping. Obviously you did not succeed in fulfilling Carlos' desire. Here's what it should have been able to look like: https://susepaste.org/view/raw/60732618 https://susepaste.org/view/raw/60602339 Yours really needs annotation, with all those home repos void of labeling what might be provided by them. Surely there will be broken synergy in the whole system with so many enabled. IMO you're lucky anything works. You have three 15.1 repos enabled. That's generally a bad configuration. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/12/2019 10.04, Felix Miata wrote:
Anton Aylward composed on 2019-12-02 20:16 (UTC-0500):
Carlos E. R. wrote:
Please do:
zypper lr --details > somefile.txt
Then attach (not paste) somefile.txt to the mail reply.
One of the reasons for using susepaste is to provide a chance of avoiding the line wrapping that makes it difficult to make sense of the output. In your paste, each line is doubly wrapped, compounding the difficulty, on top of having an insane number of repositories. Redirecting to file avoids the wrapping. Obviously you did not succeed in fulfilling Carlos' desire. Here's what it should have been able to look like:
https://susepaste.org/view/raw/60732618 https://susepaste.org/view/raw/60602339
Is the one from Anton, unwrapped? You edited it? Thanks. I prefer to open in an editor for study, so i use the download link.
Yours really needs annotation, with all those home repos void of labeling what might be provided by them. Surely there will be broken synergy in the whole system with so many enabled. IMO you're lucky anything works.
You have three 15.1 repos enabled. That's generally a bad configuration.
I see three 15.1 home repos which really should be switched to 15.0: LightZone, darktable, napobear. Anton, you should purge the home repos, and leave only those that you really-really use. I suppose most of those are for specific packages. Then, at least while your system has problems, I would at least disable: KDE:Qt5 150_KDE:Extra 150_KDE_Framework5 150 KDE_Framework5_Leap 150 KDE_Qt5_Leap 150_X11_Xorg 150_Leap_Utilities ? 150_Printing ? 150_graphics ? Then change everything that came from them to the versions in OSS. Then, if you feel the need to newer things, go for Leap 15.1 first. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeZLpwAKCRC1MxgcbY1H 1atxAJ4igUfalAFK847KDBVcMlpw5z0ZRACgieIbOB5uNVt2+aQ3HAy2gjV6HgA= =WF9C -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/12/2019 06:49, Carlos E. R. wrote:
On 03/12/2019 10.04, Felix Miata wrote:
Anton Aylward composed on 2019-12-02 20:16 (UTC-0500):
I see three 15.1 home repos which really should be switched to 15.0: LightZone, darktable, napobear.
Indeed. if you looked you see that a) those are all concerned with photo editing tools b) they don't have 15.0 versions c) they are disabled, pending
Anton, you should purge the home repos, and leave only those that you really-really use. I suppose most of those are for specific packages.
Indeed. For example, the photo editing tools They get updated a lot more frequently than the main SUSE repositories. # zypper info darktable Loading repository data... Reading installed packages... Information for package darktable: ---------------------------------- Repository : home:darix:darktable:master Name : darktable Version : 3.0.0rc2~git56.a24e84de4-lp151.2205.1 Arch : x86_64 Vendor : obs://build.opensuse.org/home:darix
Then, at least while your system has problems, I would at least disable:
KDE:Qt5 150_KDE:Extra 150_KDE_Framework5 150 KDE_Framework5_Leap 150 KDE_Qt5_Leap
Yes, those were keeping 42.3 up on theKDE5. Is there a 'bleeding edge' for KDE I should be looking for now?
150_X11_Xorg
150_Leap_Utilities ?
I can't recall why I added that, i'll check in the morining.
150_Printing ? 150_graphics ?
Specific things I needed when living in 42.3 remind me again the RPM details to search by repository to see what I'm using that comes from each of the above? I'll deal with that in my AM, which is a few hours bhind your, and update yu on the problems I did have. Which were NOTING to do with the above.
Then change everything that came from them to the versions in OSS. Then, if you feel the need to newer things, go for Leap 15.1
-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/12/2019 05.34, Anton Aylward wrote:
On 03/12/2019 06:49, Carlos E. R. wrote:
On 03/12/2019 10.04, Felix Miata wrote:
Anton Aylward composed on 2019-12-02 20:16 (UTC-0500):
I see three 15.1 home repos which really should be switched to 15.0: LightZone, darktable, napobear.
Indeed. if you looked you see that a) those are all concerned with photo editing tools b) they don't have 15.0 versions c) they are disabled, pending
Ok. I don't know what each home repo is for, but I see many enabled. Disabled are Kernel_Stable and home:siegel, X11:Utilities, and home:derselbst. Most are enabled.
Anton, you should purge the home repos, and leave only those that you really-really use. I suppose most of those are for specific packages.
Indeed. For example, the photo editing tools They get updated a lot more frequently than the main SUSE repositories. # zypper info darktable
...
Then, at least while your system has problems, I would at least disable:
KDE:Qt5 150_KDE:Extra 150_KDE_Framework5 150 KDE_Framework5_Leap 150 KDE_Qt5_Leap
Yes, those were keeping 42.3 up on theKDE5. Is there a 'bleeding edge' for KDE I should be looking for now?
I don't follow the development of KDE much. IMO, you should disable them for now, and install instead the default 15.0 packages. Then change to 15.1 ASAP. Then, *after* 15.1 is working as it should, consider what KDE repos you might want.
150_X11_Xorg
150_Leap_Utilities ?
I can't recall why I added that, i'll check in the morining.
150_Printing ? 150_graphics ?
Specific things I needed when living in 42.3
OP, so better disable those things before dupping. Printing is usually needed when purchasing a new printer.
remind me again the RPM details to search by repository to see what I'm using that comes from each of the above?
rpm -q -a --queryformat "%{INSTALLTIME};%{INSTALLTIME:day}; \ %{BUILDTIME:day}; %{NAME};%{VERSION}-%-7{RELEASE};%{arch}; \ %{VENDOR};%{PACKAGER};%{DISTRIBUTION};%{DISTTAG}\n" \ | sort | cut --fields="2-" --delimiter=\; \ | tee rpmlist.csv | less -S or rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" \ | sort | cut --fields="2-" | tee rpmlist | less -S or rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" \ | sort | cut --fields="2-" | tee rpmlist \ | egrep -v "openSUSE Leap 15\.1|openSUSE_Leap_15.1" | less -S (not containing 15.1) There is another concoction I have to find to print repository names. zypper, list of packages from a repository zypper --no-refresh se -s -r Ext_cincv zypper --no-refresh se -s -r OBS_Emulators_Wine zypper, list of packages installed from a repository zypper --no-refresh se -s -i -r OBS_Emulators_Wine | sed 's/ *| */,/g' ToDo: concoct a script to list all repos, then find all package from each. Plus those from none.
I'll deal with that in my AM, which is a few hours bhind your, and update yu on the problems I did have. Which were NOTING to do with the above.
KDE problems. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeeeHQAKCRC1MxgcbY1H 1YB3AJ4zRzw2SiB4BM/cwHGxjt+iPmTRUQCfZGPraIEQ7heiIBu+7WA3FMYHWws= =jxjU -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. composed on 2019-12-04 12:53 (UTC+0100):
IMO, you should disable them for now, and install instead the default 15.0 packages.
That's more or less just a restatement of official policy: https://en.opensuse.org/SDB:System_upgrade [quote]remove all third party/OBS repos you no longer need # zypper rr <alias> If a version of the repo exists for the new version, you can disable the repo instead of removing and after upgrading re-enable[/quote]
Then change to 15.1 ASAP. Then, *after* 15.1 is working as it should, consider what KDE repos you might want.
+++ Since you need to get to 15.1 soon anyway, you have a chance to get the resolver to fully resolve instead of leaving conflicts. Quite simply: 1: disable or remove *all* optional repos 2: zypper dup 3: confirm success, rebooting or restarting X if necessary 4: change all of /etc/zypp/repos.d/*.repo from 15.0 to 15.1 5: zypper dup 6: confirm success by rebooting with new kernel 7: add back/reenable optional repos that you still require in 15.1, one at a time 8: confirm success, restarting X if necessary 9: if another optional remains to be done, goto 7 -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/12/2019 13.44, Felix Miata wrote:
Carlos E. R. composed on 2019-12-04 12:53 (UTC+0100):
IMO, you should disable them for now, and install instead the default 15.0 packages.
That's more or less just a restatement of official policy: https://en.opensuse.org/SDB:System_upgrade [quote]remove all third party/OBS repos you no longer need
# zypper rr <alias>
If a version of the repo exists for the new version, you can disable the repo instead of removing and after upgrading re-enable[/quote]
Being a bit nitpick, the community writes that documentation. For example, /I/ wrote most of the offline upgrade wiki page. :-D I would qualify that policy: Remove or disable all extra repos that provide updated versions of what is available on the oss repo. Remove or disable all home repos for things that are available elsewhere. Which can be a purpose repo like "graphics", or the generic oss repo. Keep packman and nvidia repos: those that are for a specific purpose that oss does not cover. If you remove all repos, "zypper dup" will warn of every changed package, which is a nuisance, and they have to be undone later anyway. For example removing nvidia yields nonworking graphics. But keeping repos for kde, gnome, xfce... is asking for trouble. Use the default and tested distribution at least initially, and leave the decision to update later.
Then change to 15.1 ASAP. Then, *after* 15.1 is working as it should, consider what KDE repos you might want.
+++
Since you need to get to 15.1 soon anyway, you have a chance to get the resolver to fully resolve instead of leaving conflicts. Quite simply:
1: disable or remove *all* optional repos 2: zypper dup 3: confirm success, rebooting or restarting X if necessary
I would skip 2 and 3.
4: change all of /etc/zypp/repos.d/*.repo from 15.0 to 15.1 5: zypper dup 6: confirm success by rebooting with new kernel 7: add back/reenable optional repos that you still require in 15.1, one at a time 8: confirm success, restarting X if necessary 9: if another optional remains to be done, goto 7
- -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeexGwAKCRC1MxgcbY1H 1bNfAJ9cXaN2NvZY7zZgUcfeUkDCrcEjtwCfTBJeAm80vtMZzBEkOaW5uPCrYjc= =BSyg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. composed on 2019-12-04 14:14 (UTC+0100):
Felix Miata wrote:
That's more or less just a restatement of official policy: https://en.opensuse.org/SDB:System_upgrade [quote]remove all third party/OBS repos you no longer need
# zypper rr <alias>
If a version of the repo exists for the new version, you can disable the repo instead of removing and after upgrading re-enable[/quote]
Being a bit nitpick, the community writes that documentation. For example, /I/ wrote most of the offline upgrade wiki page. :-D
I would qualify that policy:
Sorry for using the wrong URL for official policy, which is: <https://doc.opensuse.org/documentation/leap/archive/15.0/startup/html/book.opensuse.startup/cha.update.osuse.html#sec.update.zypper> Policy from that URL: To avoid unexpected errors during the upgrade process using zypper, minimize risky constellations. 1:Quit as many applications and stop unneeded services as possible and log out all regular users. 2:Disable third party repositories before starting the upgrade, or lower the priority of these repositories to make sure packages from the default system repositories will get preference. Enable them again after the upgrade and edit their version string to match the version number of the distribution of the upgraded now running system. ... Disable third party repositories or other Open Build Service repositories, because zypper dup is guaranteed to work with the default repositories only... -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/12/2019 17.12, Felix Miata wrote:
Carlos E. R. composed on 2019-12-04 14:14 (UTC+0100):
Felix Miata wrote:
That's more or less just a restatement of official policy: https://en.opensuse.org/SDB:System_upgrade [quote]remove all third party/OBS repos you no longer need
# zypper rr <alias>
If a version of the repo exists for the new version, you can disable the repo instead of removing and after upgrading re-enable[/quote]
Being a bit nitpick, the community writes that documentation. For example, /I/ wrote most of the offline upgrade wiki page. :-D
I would qualify that policy:
Sorry for using the wrong URL for official policy, which is:
Policy from that URL:
which is very old. Zypper has been very much improved after that writing.
To avoid unexpected errors during the upgrade process using zypper, minimize risky constellations.
1:Quit as many applications and stop unneeded services as possible and log out all regular users.
2:Disable third party repositories before starting the upgrade, or lower the priority of these repositories to make sure packages from the default system repositories will get preference. Enable them again after the upgrade and edit their version string to match the version number of the distribution of the upgraded now running system.
... Disable third party repositories or other Open Build Service repositories, because zypper dup is guaranteed to work with the default repositories only...
Yes, but disabling third party repositories is sure to cause disaster. If you disable nvidia, for instance, many systems that will not boot in graphical mode and have to be "repaired". If you disable packman, you know that multimedia will not work and has to be repaired. Sure that both are untested, but in those machines where they have to be used, the upgrade works better with them enabled. So, the purist policy is to disable all repos except the official 2 (not even the update repos can stay) but the practical policy is not. Then there are other cases, like machines with optimus. I don't know what to recommend for those. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E. R. composed on 2019-12-04 14:14 (UTC+0100):
removing nvidia yields nonworking graphics. While it's certainly true that it's common, it doesn't happen here. I have dozens and dozens of installations running on NVidia GPUs. Every one of them is running satisfactorily exclusively on FOSS. My PCs are tools, not toys dependent on evolving technology. It's NVidia's tainting in /lib/ that causes people trouble when an upgrade occurs without first removing the taint, the intangible NVidia tax I choose not to pay. -- Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/12/2019 07:44, Felix Miata wrote:
Since you need to get to 15.1 soon anyway, you have a chance to get the resolver to fully resolve instead of leaving conflicts. Quite simply:
1: disable or remove *all* optional repos 2: zypper dup 3: confirm success, rebooting or restarting X if necessary 4: change all of /etc/zypp/repos.d/*.repo from 15.0 to 15.1 5: zypper dup 6: confirm success by rebooting with new kernel 7: add back/reenable optional repos that you still require in 15.1, one at a time 8: confirm success, restarting X if necessary 9: if another optional remains to be done, goto 7
And that's what borked a few of my packages. You recall I said that I, correctly, 'zypper dup' before changes repos 42.3 -> 15.0. Well that upgraded TBird from the Mozilla repo to 68.2.2 if you check out the Mozillla TBird page you'll note that it mentions problems with the 68 family were you can't regress without loosing all your accounts and having to reinstall. Well I did 'zypper up' after the change in repos numbers, and as you guys pointed out that was a mistake, and I repaired it by, later' doing the 'dup'. Which borked my Thunderbird. You might have noticed that I wasn't communicating for a day. My Tbird was borked. I only had my GMail on my phone :-( Yes, the 15.0 and 15.1 numbering went backwards from the 42.3 No 68.2.2 available, only the 68.1 series. And that included the Mozilla repo. The RPMFIND site had 68.2.2 for magia and FC but I'm not touching those! So I've reset the Mozilla repo to 42.3 and got my 68.2.2 back in place of 15.0's 68.1.1 and pulled by the accounts I was using. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/12/2019 15.18, Anton Aylward wrote:
Well I did 'zypper up' after the change in repos numbers, and as you guys pointed out that was a mistake, and I repaired it by, later' doing the 'dup'. Which borked my Thunderbird.
You might have noticed that I wasn't communicating for a day. My Tbird was borked. I only had my GMail on my phone :-(
Yes, the 15.0 and 15.1 numbering went backwards from the 42.3 No 68.2.2 available, only the 68.1 series. And that included the Mozilla repo.
15.1 has 68.2 by default. I told you to go to 15.1 ASAP. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 04/12/2019 09:21, Carlos E.R. wrote:
On 04/12/2019 15.18, Anton Aylward wrote:
Well I did 'zypper up' after the change in repos numbers, and as you guys pointed out that was a mistake, and I repaired it by, later' doing the 'dup'. Which borked my Thunderbird.
You might have noticed that I wasn't communicating for a day. My Tbird was borked. I only had my GMail on my phone :-(
Yes, the 15.0 and 15.1 numbering went backwards from the 42.3 No 68.2.2 available, only the 68.1 series. And that included the Mozilla repo.
15.1 has 68.2 by default. I told you to go to 15.1 ASAP.
Not until I stabilize where I am now. When i looked in the 15.1 repo I didn't see a 68.2.2 ... And anyway, you've already criticised me for having a few 15.1 repos scattered in there .. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/12/2019 15.38, Anton Aylward wrote:
On 04/12/2019 09:21, Carlos E.R. wrote:
On 04/12/2019 15.18, Anton Aylward wrote:
Well I did 'zypper up' after the change in repos numbers, and as you guys pointed out that was a mistake, and I repaired it by, later' doing the 'dup'. Which borked my Thunderbird.
You might have noticed that I wasn't communicating for a day. My Tbird was borked. I only had my GMail on my phone :-(
Yes, the 15.0 and 15.1 numbering went backwards from the 42.3 No 68.2.2 available, only the 68.1 series. And that included the Mozilla repo.
15.1 has 68.2 by default. I told you to go to 15.1 ASAP.
Not until I stabilize where I am now.
It will be easier to do that process on 15.1. And 15.0 is already EOL, so maintainers are probably deleting repos as we write.
When i looked in the 15.1 repo I didn't see a 68.2.2 ...
Sorry, I am using 68.2.1, not 68.2.2. I have the default version.
And anyway, you've already criticised me for having a few 15.1 repos scattered in there ..
On a 15.0 machine. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXefuHgAKCRC1MxgcbY1H 1X0tAJ9fSnMVs+pqOqH6abo1U1Sdvk+yyACfWFhBTiGsOOHxJSZO7Y/m9P8yCrU= =UhoS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward composed on 2019-12-04 09:18 (UTC-0500):
You recall I said that I, correctly, 'zypper dup' before changes repos 42.3 -> 15.0. Well that upgraded TBird from the Mozilla repo to 68.2.2 if you check out the Mozillla TBird page you'll note that it mentions problems with the 68 family were you can't regress without loosing all your accounts and having to reinstall.
Well I did 'zypper up' after the change in repos numbers, and as you guys pointed out that was a mistake, and I repaired it by, later' doing the 'dup'. Which borked my Thunderbird.
I don't let package management decide when to upgrade certain apps, mozilla.org products in particular. Virtually always I have multiple versions open at once, so cannot depend on a distro's choice of version anyway. Instead, I use the binaries provided on mozilla.org: http://ftp.mozilla.org/pub/firefox/ http://ftp.mozilla.org/pub/seamonkey/ http://ftp.mozilla.org/pub/thunderbird/releases/ I can have as many versions as I want or need all at once, kept in /usr/local/ directories, and with multiple user profiles in one consolidated location. # zypper --no-refresh se -s -i $* | egrep -v 'debug|devel|srcp|openSUSE-20' | egrep 'x86|noarch'| sort i | ca-certificates-mozilla | package | 2.34-lp151.2.3.1 | noarch | Update i+ | mozilla-nspr | package | 4.21-lp151.2.3.1 | x86_64 | Update i+ | mozilla-nss | package | 3.45-lp151.2.6.1 | x86_64 | Update i+ | mozilla-nss-certs | package | 3.45-lp151.2.6.1 | x86_64 | Update When I have trouble, which is infrequent, I goto IRC, where competent help is usually swift: irc://moznet/#firefox irc://moznet/#seamonkey irc://moznet/#thunderbird -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 4 Dec 2019 09:18:31 -0500 Anton Aylward <opensuse@antonaylward.com> wrote:
On 04/12/2019 07:44, Felix Miata wrote:
Since you need to get to 15.1 soon anyway, you have a chance to get the resolver to fully resolve instead of leaving conflicts. Quite simply:
1: disable or remove *all* optional repos 2: zypper dup 3: confirm success, rebooting or restarting X if necessary 4: change all of /etc/zypp/repos.d/*.repo from 15.0 to 15.1 5: zypper dup 6: confirm success by rebooting with new kernel 7: add back/reenable optional repos that you still require in 15.1, one at a time 8: confirm success, restarting X if necessary 9: if another optional remains to be done, goto 7
And that's what borked a few of my packages.
Err, did it?
You recall I said that I, correctly, 'zypper dup' before changes repos 42.3 -> 15.0. Well that upgraded TBird from the Mozilla repo to 68.2.2
Step 1 included disabling or removing the Mozilla repo before the dup, so you can't have done that properly! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/12/2019 07:44, Felix Miata wrote:
That's more or less just a restatement of official policy: https://en.opensuse.org/SDB:System_upgrade [quote]remove all third party/OBS repos you no longer need
"Need" being the operative word. What's up with KDE5/plasma that I can't seem to find out of the 'extras' and 'framework'. I'm open to suggestions, but please don't tell me to move to 15.1 after all this trauma involved in one upgrade. WHICH IS NOT YET STABLE AND FULLY FUNCTIONAL! Too many changes, things in 15.90 that weren't in 42.3 and things that are missing from 42.3 that I was using. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/12/2019 15.44, Anton Aylward wrote:
On 04/12/2019 07:44, Felix Miata wrote:
That's more or less just a restatement of official policy: https://en.opensuse.org/SDB:System_upgrade [quote]remove all third party/OBS repos you no longer need
"Need" being the operative word.
What's up with KDE5/plasma that I can't seem to find out of the 'extras' and 'framework'.
Dunno, but may have been deleted. Remember that 15.0 is EOL.
I'm open to suggestions, but please don't tell me to move to 15.1 after all this trauma involved in one upgrade.
WHICH IS NOT YET STABLE AND FULLY FUNCTIONAL!
Precisely the reason I tell you to go to 15.1. You will work double doing it first in 15.0 then in 15.1. The distance from 42.3 to 15.0 is a major, while 15.0 to 15.1 is minor. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXefwWgAKCRC1MxgcbY1H 1Y1GAKCCIlNT4kd16DcenRAoI2RfOYLV+wCfYbqgDLCffC5D8yuwKFdr5hZaGok= =tG4P -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/12/2019 12:43, Carlos E. R. wrote:
On 04/12/2019 15.44, Anton Aylward wrote:
On 04/12/2019 07:44, Felix Miata wrote:
That's more or less just a restatement of official policy: https://en.opensuse.org/SDB:System_upgrade [quote]remove all third party/OBS repos you no longer need
"Need" being the operative word.
What's up with KDE5/plasma that I can't seem to find out of the 'extras' and 'framework'.
Dunno, but may have been deleted. Remember that 15.0 is EOL.
As I said, I'm stabilising where I am first. Operating System: openSUSE Leap 15.0 KDE Plasma Version: 5.17.3 KDE Frameworks Version: 5.64.0 Qt Version: 5.13.1 Kernel Version: 5.2.14-2.g7f85414-default OS Type: 64-bit Processors: 4 × Intel® Core™2 Quad CPU Q6600 @ 2.40GHz Memory: 7.6 GiB of RAM
I'm open to suggestions, but please don't tell me to move to 15.1 after all this trauma involved in one upgrade.
WHICH IS NOT YET STABLE AND FULLY FUNCTIONAL!
Precisely the reason I tell you to go to 15.1. You will work double doing it first in 15.0 then in 15.1.
The distance from 42.3 to 15.0 is a major, while 15.0 to 15.1 is minor.
Well I've deleted some of the repositories you've suggested, and now a 'zypper up' wants to to bring in a new couple of hundred. So I think this is a long way from stable. And, annoyingly, the bandwidth is very low for some reason. So this is going to take a few more days just staring it then going off to read a thick book. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward composed on 2019-12-04 13:38 (UTC-0500):
And, annoyingly, the bandwidth is very low for some reason. So this is going to take a few more days just staring it then going off to read a thick book.
When release support expires, many (most?) mirrors purge it. Thus mirrorbrain is more likely to give you a less favorable mirror. This for me is routine, as my primary DE is KDE3, which too frequently (often more than thrice a month) is largely rebuilt, but only lives on a mirror subset, as do most optional repos. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/12/2019 23:34, Anton Aylward wrote:
I see three 15.1 home repos which really should be switched to 15.0: LightZone, darktable, napobear. Indeed. if you looked you see that a) those are all concerned with photo editing tools b) they don't have 15.0 versions c) they are disabled, pending
"Pending" is true! As I said earlier, we're dealing with replies and lags and threads and time zones and my paying attention to Patrick and re-editing and doing many things. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/12/2019 04:04, Felix Miata wrote:
One of the reasons for using susepaste is to provide a chance of avoiding the line wrapping that makes it difficult to make sense of the output.
Yes, I appreciated that.
In your paste, each line is doubly wrapped, compounding the difficulty, on top of having an insane number of repositories.
I don't see how to make them not wrapped. Oh, I appreciate your example. But how to get like that?
Redirecting to file avoids the wrapping. Obviously you did not succeed in fulfilling Carlos' desire. Here's what it should have been able to look like:
https://susepaste.org/view/raw/60732618 https://susepaste.org/view/raw/60602339
Yours really needs annotation, with all those home repos void of labeling what might be provided by them. Surely there will be broken synergy in the whole system with so many enabled. IMO you're lucky anything works.
No there is not an insane number. They grew like Topsy, a little at a time and they worked. My mistakes were elsewhere. The 15.1 are each photo applications, to do with Darktable. You'll notice of you follow the URL that there is no 15.0 repository for them. you'll also notice that they are disabled, pending. You are right about 'labelling. This system lacks that might be termed 'semantics'. And yes, I've uncovered an example of 42.3 having higher/later version number that 15.0, but that's for another post. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Anton Aylward <opensuse@antonaylward.com> [01-01-70 12:34]:
On 03/12/2019 04:04, Felix Miata wrote:
One of the reasons for using susepaste is to provide a chance of avoiding the line wrapping that makes it difficult to make sense of the output.
Yes, I appreciated that.
In your paste, each line is doubly wrapped, compounding the difficulty, on top of having an insane number of repositories.
I don't see how to make them not wrapped. Oh, I appreciate your example. But how to get like that?
Redirecting to file avoids the wrapping. Obviously you did not succeed in fulfilling Carlos' desire. Here's what it should have been able to look like:
https://susepaste.org/view/raw/60732618 https://susepaste.org/view/raw/60602339
Yours really needs annotation, with all those home repos void of labeling what might be provided by them. Surely there will be broken synergy in the whole system with so many enabled. IMO you're lucky anything works.
No there is not an insane number. They grew like Topsy, a little at a time and they worked. My mistakes were elsewhere.
The 15.1 are each photo applications, to do with Darktable. You'll notice of you follow the URL that there is no 15.0 repository for them. you'll also notice that they are disabled, pending.
perhaps not enough effort looking for packages ??? https://download.opensuse.org/repositories/graphics:/darktable:/master/openS... https://download.opensuse.org/repositories/graphics:/darktable:/master/openS... https://download.opensuse.org/repositories/graphics:/darktable:/stable/openS... https://download.opensuse.org/repositories/graphics:/darktable:/stable/openS...
You are right about 'labelling. This system lacks that might be termed 'semantics'.
And yes, I've uncovered an example of 42.3 having higher/later version number that 15.0, but that's for another post.
-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon?
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/12/2019 23:16, Patrick Shanahan wrote:
perhaps not enough effort looking for packages ???
https://download.opensuse.org/repositories/graphics:/darktable:/master/openS... https://download.opensuse.org/repositories/graphics:/darktable:/master/openS...
https://download.opensuse.org/repositories/graphics:/darktable:/stable/openS... https://download.opensuse.org/repositories/graphics:/darktable:/stable/openS...
You'll also notice that I have that: "darktable.stable" The 'pending' on 'darix' was 'pending deletion' -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/12/2019 15.10, Anton Aylward wrote:
On 02/12/2019 02:19, David C. Rankin wrote:
On 12/01/2019 08:02 PM, Anton Aylward wrote:
On 01/12/2019 20:21, Carlos E. R. wrote:
...
OK. Overnight I ran the "dup". Nearly 2,000 changes.
As I said, regressing. The initial 'Up" gave men TB 68.2.2 The "dup" gave me MozillaThunderbird-68.2.1
I now get
# zypper up MozillaThunderbird There is an update candidate for 'MozillaThunderbird' from vendor 'openSUSE', while the current vendor is 'obs://build.opensuse.org/mozilla'. Use 'zypper install MozillaThunderbird-68.2.1-lp150.3.54.1.x86_64' to install this candidate. There is an update candidate for 'MozillaThunderbird', but it comes from a repository with a lower priority. Use 'zypper install MozillaThunderbird-68.2.1-lp150.3.54.1.x86_64' to install this candidate.
Guess: you have too many repos.
So where did 68.2.2 come from in my initial "up"?
I find that out with YaST. Version tab.
After running the "dup" I try running a "up" and a "patch" and find there are quite a number of regressions.
Too many repos :-P - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeVisgAKCRC1MxgcbY1H 1YBKAJ9gLcGIiokfGRTc0EcV7XQHuG7PdACcD0xwJ/vfaEjP4khuu9MaQhmaH+U= =n/CS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/12/2019 14:16, Carlos E. R. wrote:
On 01/12/2019 19.58, Anton Aylward wrote:
# rpm -qf /usr/lib64/libmodman.so.1 libmodman1-2.0.1-20.3.x86_64
That's not from 15.0.
http://download.opensuse.org/distribution/leap/15.0/repo/oss/x86_64/
So I go there and get the libmonman rpm using ftp and try installing it # rpm -iv libmodman1-2.0.1-lp150.1.6.x86_64.rpm Preparing packages... package libmodman1-2.0.1-20.3.x86_64 (which is newer than libmodman1-2.0.1-lp150.1.6.x86_64) is already installed file /usr/lib64/libmodman.so.1.0.0 from install of libmodman1-2.0.1-lp150.1.6.x86_64 conflicts with file from package libmodman1-2.0.1-20.3.x86_64 Please advise
-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Sun, 01 Dec 2019, Anton Aylward wrote:
So I go there and get the libmonman rpm using ftp and try installing it
# rpm -iv libmodman1-2.0.1-lp150.1.6.x86_64.rpm Preparing packages... package libmodman1-2.0.1-20.3.x86_64 (which is newer than libmodman1-2.0.1-lp150.1.6.x86_64) is already installed file /usr/lib64/libmodman.so.1.0.0 from install of libmodman1-2.0.1-lp150.1.6.x86_64 conflicts with file from package libmodman1-2.0.1-20.3.x86_64
Please advise
rpm -Uvh .... Same goes for the '-ivh' in my mail which should replaced by '-Uvh'. (and if in doubt and you're sure, use '--nodeps --force' as zypp does)... -dnh -- Q: Hobbies? A: Hating music. -- Marvin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/12/2019 19:51, David Haller wrote:
(and if in doubt and you're sure, use '--nodeps --force' as zypp does)...
I suspect that this "--force" would get around the 42.3 > 15.0 revision number issue, but it makes me very nervous. How many more of these? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/12/2019 02.11, Anton Aylward wrote:
On 01/12/2019 19:51, David Haller wrote:
(and if in doubt and you're sure, use '--nodeps --force' as zypp does)...
I suspect that this "--force" would get around the 42.3 > 15.0 revision number issue, but it makes me very nervous. How many more of these?
1500 or so, if you have to go one by one... At some point you have to use "zypper dup" once the repos are correct. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeRndQAKCRC1MxgcbY1H 1ck0AJ9SFv+QiU+4mvMmq7Rn8VrQcr6KHQCgheoIzODkB74EJSfxIZxYpqkvrQs= =agQ/ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Sun, 01 Dec 2019, Anton Aylward wrote:
On 01/12/2019 19:51, David Haller wrote:
(and if in doubt and you're sure, use '--nodeps --force' as zypp does)...
I suspect that this "--force" would get around the 42.3 > 15.0 revision number issue, but it makes me very nervous. How many more of these?
Just until 'zypper dup --dry-run' works. You successfully borked your system by using the wrong combination of 'zypper up' and repo config (or something amounting to the same thing), so don't be a wuss, get zypper running again via the process I described in that long mail (using rpm directly; if needed from a rescue system). Then fix your /etc/zypp/repos.d/*! ALL OF It! Prune it to the single plain 'oss' repo if neccesssary[3] (just move the rest to another (versioned) subdir of /etc/zypp/ or /root/ or whereever). I just messed up/forgot[1][2] about the '-ivh' issue, but '-Uvh', '-Uvh --oldpackage', or '-Uvh --nodeps --force' (try in that order) may be required. If you're sure you've got the right packages, grab the big hammer and use the '--force'. And add '--nodeps' if you're sure. No need to be scared about it, you can't break it much more than it already is. Basically, you'll supplant your (broken) base install by a hopefully sane and working one. Oh, pro-Tip: download an install ISO from SUSE! That contains a (sane) set of tools like zypper (and all deps needed). Loop-mount that ISO (just like that or from a rescue system, say, to /mnt/DLS/ or /mnt/ISO/ or wherever), and then apply my strategy using the packages from that mountpoint. And, in your case, following the whole shebang up with a 'zypper dup' once zypper works again (repeatedly, until it tells you there's nothing to do), it should all be clear without leftovers... HTH, -dnh PS: You'll be happy to have fixed your system "from the ground up" [1] it's been a while, ISTR I migrated from 11.2 32bit to 11.4 64bit, 10 years ago? Anyway, details get lost in memory corruption... [2] the principle, i.e. fix it via rpm (via rescue system) is still valid. And I put that to the test more recently (Gen)too ;) [3] I've always kept other repos live while updating. Well, those where the new version was available which I checked _BEFORE_ ... The rest got disabled/moved away. There's pros and cons about that during the 'zypper dup', and I understand that it's recommended to disable all other repos but 'oss'. Going through each repo and checking that each repo is live and well for the to-be-dup-ed-to version is, well, a bit tedious and not "end-user-compatible" or something like that... --
What is it with word processors anyway? "Well, you've seen what food processors do to food...." -- Steve Willoughby and Alan Shutko quoting (IHRC) David Carlisle in asr
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* David Haller <dnh@opensuse.org> [12-01-19 21:55]:
Hello,
On Sun, 01 Dec 2019, Anton Aylward wrote:
On 01/12/2019 19:51, David Haller wrote:
(and if in doubt and you're sure, use '--nodeps --force' as zypp does)...
I suspect that this "--force" would get around the 42.3 > 15.0 revision number issue, but it makes me very nervous. How many more of these?
Just until 'zypper dup --dry-run' works.
aiui, "--dry-run" is really superfluous. zypper -v ref ; zypper -v dup -d ; zypper -v dup will refresh, then download all, then request permission to proceed with installing the packages. if zypper is not working, it will complain, early. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/12/2019 03.52, David Haller wrote:
[3] I've always kept other repos live while updating. Well, those where the new version was available which I checked _BEFORE_ ... The rest got disabled/moved away. There's pros and cons about that during the 'zypper dup', and I understand that it's recommended to disable all other repos but 'oss'. Going through each repo and checking that each repo is live and well for the to-be-dup-ed-to version is, well, a bit tedious and not "end-user-compatible" or something like that...
I keep the "minimum" of repos active while doing the dup. That is, oss, non-oss, updates, and packman. If, for instance, I have made updates to the desktops, I remove those. But I use packages that are only on extra repos, I keep those enabled. The thinking is that removing packman will make zypper try to change repos and post a thousand questions if I'm sure. Similarly for extra repos, those packages may disapear or be kept depending on the questions. And about updates to the desktops, better go to the default oss version, and when things work decide if I want newer versions. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeSC6wAKCRC1MxgcbY1H 1Sd6AJ9AGz1UQuIHIS8lhTaGg5fqSF3z3QCfXn154rZiYJsHuiVEaPRtFcP5OCk= =jQ5f -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward composed on 2019-12-01 19:25 (UTC-0500):
# rpm -iv libmodman1-2.0.1-lp150.1.6.x86_64.rpm Preparing packages... package libmodman1-2.0.1-20.3.x86_64 (which is newer than libmodman1-2.0.1-lp150.1.6.x86_64) is already installed file /usr/lib64/libmodman.so.1.0.0 from install of libmodman1-2.0.1-lp150.1.6.x86_64 conflicts with file from package libmodman1-2.0.1-20.3.x86_64
rpm won't update an installed package by "installing" it. Instead, upgrade: # rpm -Uv libmodman1-2.0.1-lp150.1.6.x86_64.rpm 15.0 started a new versioning cycle, or something like that, with some packages, so some older packages to rpm look newer. With those, the --oldpackage option is also required with -U. If it still refuses, I rpm -e --nodeps the old package, # rpm -Uv --oldpackage libmodman1-2.0.1-lp150.1.6.x86_64.rpm zypper dup is smarter than rpm, so: # zypper -v in --oldpackage libmodman1-2.0.1-lp150.1.6.x86_64.rpm should work for new package as well as package upgrade. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/12/2019 02.07, Felix Miata wrote:
Anton Aylward composed on 2019-12-01 19:25 (UTC-0500):
# rpm -iv libmodman1-2.0.1-lp150.1.6.x86_64.rpm Preparing packages... package libmodman1-2.0.1-20.3.x86_64 (which is newer than libmodman1-2.0.1-lp150.1.6.x86_64) is already installed file /usr/lib64/libmodman.so.1.0.0 from install of libmodman1-2.0.1-lp150.1.6.x86_64 conflicts with file from package libmodman1-2.0.1-20.3.x86_64
rpm won't update an installed package by "installing" it. Instead, upgrade:
# rpm -Uv libmodman1-2.0.1-lp150.1.6.x86_64.rpm
But using the force... rpm -Uvh --force --nodeps ... - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeRkygAKCRC1MxgcbY1H 1RmWAJ43jDqb86DIK/wdv85kdn0jRDS7vgCdFQNSAjVl3UXyks2KzF3RvP6knDI= =r/YI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Sun, 01 Dec 2019, Anton Aylward wrote:
On 01/12/2019 17.50, Anton Aylward wrote: [..]
# zypper refresh zypper: symbol lookup error: /usr/lib64/libproxy.so.1: undefined symbol:
_ZN9libmodman14module_manager8load_dirENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb ^^^^^^^^^^^ Please note
Hum! [..]
On 01/12/2019 13:18, Carlos E. R. wrote: main:/var/log # strings /usr/lib64/libmodman.so.1|grep -i zn9 _ZN9libmodman14module_managerD2Ev _ZN9libmodman14module_managerD1Ev _ZN9libmodman14module_manager12load_builtinEP9mm_module _ZN9libmodman14module_manager9load_fileESsb _ZN9libmodman14module_manager8load_dirESsb
RTFM: man 1 c++filt $ cat <<'EOF' | c++filt _ZN9libmodman14module_manager8load_dirENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb _ZN9libmodman14module_managerD2Ev _ZN9libmodman14module_managerD1Ev _ZN9libmodman14module_manager12load_builtinEP9mm_module _ZN9libmodman14module_manager9load_fileESsb _ZN9libmodman14module_manager8load_dirESsb EOF libmodman::module_manager::load_dir(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool) libmodman::module_manager::~module_manager() libmodman::module_manager::~module_manager() libmodman::module_manager::load_builtin(mm_module*) libmodman::module_manager::load_file(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool) libmodman::module_manager::load_dir(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool) Note, too, that the switch from the old c++ strings (std::basic_string) to the c++11 ones (std::__cxx11::basic_string) requires to recompile the involved libs. In this case (having read downthread), it's probably that libmodman is not compiled with -std=c++11 nor -std=gnu++11 (because it's not from leap 15.0 but a leftover from 42.3)... So, just go and "force install" the current libmodman package from leap 15.0, possibly using plain rpm in the process or even from a rescue medium... E.g. from a rescue system with a recent enough rpm (worst case): # cd /mnt/DLS/suse/x86_64/ # rpm --test -ivh --root=/mnt/TARGET_SYS libmodman1-*.rpm (assuming you have not downloaded unnessessary file to /mnt/DLS/ like *-debug* packages or -32bit packages where unneeded). Add more packages as needed by deps, possibly using ../noarch/foo*.rpm in the process. Keep downloading, adding packages to the commandline and '--test' installing until rpm is satisfied (that's the main job that zypper does!). Once rpm is happy, omit the --test, install packages (rpm will handle the inter-package deps of those packages given on the commandline) and all should be well... BTDT[1], HTH, -dnh [1] on my borked switch from i586 to x86_64 while leaving 'arch=i586' in /etc/zypp/zypp.conf... Too bad binaries were 64bit and libs 32bit or so... IIRC not even rpm ran. Had to fix that with the above method (a level lower) from a rescue system ... Good thing I had the full install-ISO to loop-mount and install from instead of DL-ing each package in turn... -- Eh, that's it, I guess. No 300 million dollar unveiling event for this kernel, I'm afraid, but you're still supposed to think of this as the "happening of the century" (at least until the next kernel comes along). -- Linus, in the announcement for 1.3.27 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I've just met another 'woe" in the form of getting the SDDM login to work. Under 42.3 I used XDM, and part of the 'anton' login was to have a ~anton/.bash_profile that set up a lot of shell variables and ran 'keychain' the set up the PGP agent and GPG agent. SDDM did not like this. As far as I can tell, anything in the .bash_profile that prompts for input (I've turned of things like 'lxrandr' now I have DID working) causes SDDM to hang. I do not like this. I now have to manually run ~anton/.bash_profile,old after login. I've tried googling but my google-fo hasn't met anything to do with this. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/12/2019 14.05, Anton Aylward wrote:
I've just met another 'woe" in the form of getting the SDDM login to work.
Under 42.3 I used XDM, and part of the 'anton' login was to have a ~anton/.bash_profile that set up a lot of shell variables and ran 'keychain' the set up the PGP agent and GPG agent.
SDDM did not like this. As far as I can tell, anything in the .bash_profile that prompts for input (I've turned of things like 'lxrandr' now I have DID working) causes SDDM to hang.
You can not ask for user input in the graphical login process. There are various shell start scripts, each one running on different circumstances. Me, I don't do anything PGP related, that is done by the desktop start procedure.
I do not like this. I now have to manually run ~anton/.bash_profile,old after login.
I've tried googling but my google-fo hasn't met anything to do with this.
- -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXepX6QAKCRC1MxgcbY1H 1X6iAJ9522WaruBVZLhdAJMuQPxdrlis7ACghM4ymQEX7p+rKUZmJjSHieg1NZU= =ESPU -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/12/2019 08:30, Carlos E. R. wrote:
On 06/12/2019 14.05, Anton Aylward wrote:
I've just met another 'woe" in the form of getting the SDDM login to work.
Under 42.3 I used XDM, and part of the 'anton' login was to have a ~anton/.bash_profile that set up a lot of shell variables and ran 'keychain' the set up the PGP agent and GPG agent.
SDDM did not like this. As far as I can tell, anything in the .bash_profile that prompts for input (I've turned of things like 'lxrandr' now I have DID working) causes SDDM to hang.
You can not ask for user input in the graphical login process.
Granted, but these do not get called until I fire up the Konsole application, and after I login there. Or that was was the way it worked when I used XDM as a graphical login. More to the point, this is supposed to use a smart prompt mechanism that identifies the input and there are graphitic input tools for the PGP prompt. Such as 'pinentry' pinentry, pinentry-qt4, pinentry-tty, pinentry-curses, pinentry-qt, pinentry-qt5
There are various shell start scripts, each one running on different circumstances. Me, I don't do anything PGP related, that is done by the desktop start procedure.
Yes, that's my point. Why is SDDM doing this? Why isn't it deferred until the Konsole starts? I'm forced to conclude that SDDM runs a shell initially
I do not like this. I now have to manually run ~anton/.bash_profile,old after login.
I've tried googling but my google-fo hasn't met anything to do with this.
-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/12/2019 14.51, Anton Aylward wrote:
On 06/12/2019 08:30, Carlos E. R. wrote:
On 06/12/2019 14.05, Anton Aylward wrote:
I've just met another 'woe" in the form of getting the SDDM login to work.
Under 42.3 I used XDM, and part of the 'anton' login was to have a ~anton/.bash_profile that set up a lot of shell variables and ran 'keychain' the set up the PGP agent and GPG agent.
SDDM did not like this. As far as I can tell, anything in the .bash_profile that prompts for input (I've turned of things like 'lxrandr' now I have DID working) causes SDDM to hang.
You can not ask for user input in the graphical login process.
Granted, but these do not get called until I fire up the Konsole application, and after I login there.
Nono, they are used by many more processes during desktop startup.
Or that was was the way it worked when I used XDM as a graphical login.
More to the point, this is supposed to use a smart prompt mechanism that identifies the input and there are graphitic input tools for the PGP prompt. Such as 'pinentry' pinentry, pinentry-qt4, pinentry-tty, pinentry-curses, pinentry-qt, pinentry-qt5
I get those the instant I'm actually signing or opening documents, and cached for some minutes. For instant, if I send an email using Alpine (on terminal) I get a graphical prompt for the passphrase, and if minutes later I send an email using Thunderbird, I don't get asked. Similarly, sign on one terminal, use it on another terminal, transparently.
There are various shell start scripts, each one running on different circumstances. Me, I don't do anything PGP related, that is done by the desktop start procedure.
Yes, that's my point. Why is SDDM doing this? Why isn't it deferred until the Konsole starts?
I'm forced to conclude that SDDM runs a shell initially
Certainly. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXepe3wAKCRC1MxgcbY1H 1W3HAJ4sDGnVqkg0TK/1+c6HFkpCmRlmeACeLpUIdP3TnRNWqfdAZg55LXGq+nE= =TY6C -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/12/2019 09:00, Carlos E. R. wrote:
On 06/12/2019 14.51, Anton Aylward wrote:
On 06/12/2019 08:30, Carlos E. R. wrote:
On 06/12/2019 14.05, Anton Aylward wrote:
I've just met another 'woe" in the form of getting the SDDM login to work.
Under 42.3 I used XDM, and part of the 'anton' login was to have a ~anton/.bash_profile that set up a lot of shell variables and ran 'keychain' the set up the PGP agent and GPG agent.
SDDM did not like this. As far as I can tell, anything in the .bash_profile that prompts for input (I've turned of things like 'lxrandr' now I have DID working) causes SDDM to hang.
You can not ask for user input in the graphical login process.
Granted, but these do not get called until I fire up the Konsole application, and after I login there.
Nono, they are used by many more processes during desktop startup.
To my mind there is a simple issue: is this an interactive login shell? If it is something that SMMD does using a shell script then its is not interactive. It is not interactive until it is a shell started by Konsole. non-interactive scripts might use .bashrc but they shouldn't use .bash_profile or .bash_login
Or that was was the way it worked when I used XDM as a graphical login.
There are various shell start scripts, each one running on different circumstances. Me, I don't do anything PGP related, that is done by the desktop start procedure.
Yes, that's my point. Why is SDDM doing this? Why isn't it deferred until the Konsole starts?
I'm forced to conclude that SDDM runs a shell initially
Certainly.
But it shouldn't be running the login stuff if this is a 'background' start-up function. I still want the PGP/GPG start when the Konsole shells start using "/bin/bash -l"
-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/12/2019 03.36, Anton Aylward wrote:
On 06/12/2019 09:00, Carlos E. R. wrote:
On 06/12/2019 14.51, Anton Aylward wrote:
On 06/12/2019 08:30, Carlos E. R. wrote:
...
There are various shell start scripts, each one running on different circumstances. Me, I don't do anything PGP related, that is done by the desktop start procedure.
Yes, that's my point. Why is SDDM doing this? Why isn't it deferred until the Konsole starts?
I'm forced to conclude that SDDM runs a shell initially
Certainly.
But it shouldn't be running the login stuff if this is a 'background' start-up function. I still want the PGP/GPG start when the Konsole shells start using "/bin/bash -l"
Well, PGP/GPG stuff is started earlier and is ready and available when I open any terminal, CLI, or GUI program. Sl /usr/bin/sddm Ssl+ \_ /usr/bin/X -nolisten tcp -auth /run/sddm S \_ /usr/lib/sddm/sddm-helper --socket /tmp/ S \_ /bin/sh /etc/xdg/xfce4/xinitrc -- /e Ss \_ /usr/bin/ssh-agent /usr/bin/gpg- Ss \_ /usr/bin/gpg-agent --sh --daemon Sl \_ xfce4-session Sl \_ xfwm4 --display :0.0 --sm-cl Sl \_ Thunar --sm-client-id 25b4ec Sl \_ xfce4-panel --display :0.0 - ... Sl \_ xfce4-terminal --geometry=12 Ss | \_ bash S | | \_ su - astro The GUI session stuff takes care of starting the agents, not the bash profile. You are fighting the system. Let instead the system work for you. You do not need to start the agents in your bash files. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXesYVwAKCRC1MxgcbY1H 1RhuAJ4rmHEf0u9HvrHmmwvC5G/C7DJ4YQCfXhngfAC48LlqQ5bHAohKB3DQizY= =LPGg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/12/2019 22:11, Carlos E. R. wrote:
Well, PGP/GPG stuff is started earlier and is ready and available when I open any terminal, CLI, or GUI program.
Sl /usr/bin/sddm Ssl+ \_ /usr/bin/X -nolisten tcp -auth /run/sddm S \_ /usr/lib/sddm/sddm-helper --socket /tmp/ S \_ /bin/sh /etc/xdg/xfce4/xinitrc -- /e Ss \_ /usr/bin/ssh-agent /usr/bin/gpg- Ss \_ /usr/bin/gpg-agent --sh --daemon Sl \_ xfce4-session Sl \_ xfwm4 --display :0.0 --sm-cl Sl \_ Thunar --sm-client-id 25b4ec Sl \_ xfce4-panel --display :0.0 - ... Sl \_ xfce4-terminal --geometry=12 Ss | \_ bash S | | \_ su - astro
The GUI session stuff takes care of starting the agents, not the bash profile. You are fighting the system. Let instead the system work for you. You do not need to start the agents in your bash files.
I don't see an XDG for my situation, plasma/kde5 I print the process tree and there seems to be a disconnect between the stuff from SDDM, and I'm not sure how it identifies any gpg agent, and the kdeinit5 that starts up the session that I actually use, including the Konsole session. it looks nothing like what you have above. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/12/2019 04.55, Anton Aylward wrote:
On 06/12/2019 22:11, Carlos E. R. wrote:
Well, PGP/GPG stuff is started earlier and is ready and available when I open any terminal, CLI, or GUI program.
Sl /usr/bin/sddm Ssl+ \_ /usr/bin/X -nolisten tcp -auth /run/sddm S \_ /usr/lib/sddm/sddm-helper --socket /tmp/ S \_ /bin/sh /etc/xdg/xfce4/xinitrc -- /e Ss \_ /usr/bin/ssh-agent /usr/bin/gpg- Ss \_ /usr/bin/gpg-agent --sh --daemon Sl \_ xfce4-session Sl \_ xfwm4 --display :0.0 --sm-cl Sl \_ Thunar --sm-client-id 25b4ec Sl \_ xfce4-panel --display :0.0 - ... Sl \_ xfce4-terminal --geometry=12 Ss | \_ bash S | | \_ su - astro
The GUI session stuff takes care of starting the agents, not the bash profile. You are fighting the system. Let instead the system work for you. You do not need to start the agents in your bash files.
I don't see an XDG for my situation, plasma/kde5
I print the process tree and there seems to be a disconnect between the stuff from SDDM, and I'm not sure how it identifies any gpg agent, and the kdeinit5 that starts up the session that I actually use, including the Konsole session. it looks nothing like what you have above.
Well, I use XFCE. The trick in XFCE is to "Launch Gnome services on startup", under All settings/Advanced. Then in the list of applications automatically started I see "Certificate and Key Storage", "SSH Key Agent", "Seahorse Key Agent" (Remember PGP passphrase)" (and it is possible there is an even better way) Surely KDE has equivalent settings. Create a new user, login, and find the graphical tool to create PGP keys. There must be a setting to handle the agents. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeu23wAKCRC1MxgcbY1H 1du5AJsF0eFAjyGyG2Zt7U2rVKKBuFUCxgCfce49xRpNLzCku2ecJofJTRVlsqw= =ZoVF -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/12/2019 09:27, Carlos E. R. wrote:
On 07/12/2019 04.55, Anton Aylward wrote:
On 06/12/2019 22:11, Carlos E. R. wrote:
Well, PGP/GPG stuff is started earlier and is ready and available when I open any terminal, CLI, or GUI program.
[snip] The GUI session stuff takes care of starting the agents, not the bash profile. You are fighting the system. Let instead the system work for you. You do not need to start the agents in your bash files.
I don't see an XDG for my situation, plasma/kde5
I print the process tree and there seems to be a disconnect between the stuff from SDDM, and I'm not sure how it identifies any gpg agent, and the kdeinit5 that starts up the session that I actually use, including the Konsole session. it looks nothing like what you have above.
Well, I use XFCE. The trick in XFCE is to "Launch Gnome services on startup", under All settings/Advanced. ^^^^^^^^^^^^^^^^^^^^^
So what's the KDE equivalent? I look at what's under 'systemsettings5' and it is heavily itemized. Obviously this is not 'appearance', but it's not yast either. "Start up"? Well "autostart" starts up 'fetchmail' but it doesn't offer a menu of what's available. I did put in lxrandr to set to 1280x1024 initially 'cos for some reason the DID wasn't seen, but now it is so that's turned off. There's a whole pile of 'background services and startup services that make up KDE but the GPG/PGP isn't among them. These are things like the device notifier, removable device automounter, touchpad and WATCOM pad managers. There doesn't seem to be any way to add to these.
Then in the list of applications automatically started I see "Certificate and Key Storage", "SSH Key Agent", "Seahorse Key Agent" (Remember PGP passphrase)"
(and it is possible there is an even better way)
Surely KDE has equivalent settings.
The best I can see is the 'autostart', but that get back to this issue of manual input of the secret phrase.
Create a new user, login, and find the graphical tool to create PGP keys. There must be a setting to handle the agents.
I've always done it manually in the shell starup. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/12/2019 16.27, Anton Aylward wrote:
On 07/12/2019 09:27, Carlos E. R. wrote:
On 07/12/2019 04.55, Anton Aylward wrote:
On 06/12/2019 22:11, Carlos E. R. wrote:
Well, I use XFCE. The trick in XFCE is to "Launch Gnome services on startup", under All settings/Advanced. ^^^^^^^^^^^^^^^^^^^^^
So what's the KDE equivalent? I look at what's under 'systemsettings5' and it is heavily itemized. Obviously this is not 'appearance', but it's not yast either. "Start up"? Well "autostart" starts up 'fetchmail' but it doesn't offer a menu of what's available. I did put in lxrandr to set to 1280x1024 initially 'cos for some reason the DID wasn't seen, but now it is so that's turned off.
I was going to try. I created a new user, but "switch user" suddenly doesn't work, does nothing, and nothing in the log :-/ I can not at this instant log out of this session, I have unfinished tasks.
There's a whole pile of 'background services and startup services that make up KDE but the GPG/PGP isn't among them. These are things like the device notifier, removable device automounter, touchpad and WATCOM pad managers. There doesn't seem to be any way to add to these.
There is a KDE app to manage GPG keys. I know because I have used it. Kleopatra, I think.
Then in the list of applications automatically started I see "Certificate and Key Storage", "SSH Key Agent", "Seahorse Key Agent" (Remember PGP passphrase)"
(and it is possible there is an even better way)
Surely KDE has equivalent settings.
The best I can see is the 'autostart', but that get back to this issue of manual input of the secret phrase.
Create a new user, login, and find the graphical tool to create PGP keys. There must be a setting to handle the agents.
I've always done it manually in the shell starup.
That's not the correct way in 2019. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXevNAgAKCRC1MxgcbY1H 1SoRAJoC7O/6SOn7pJiMldGbAKOBpMfpwACdENXwwsRGiV9WaB9dKI+bbLQtSKA= =CpH/ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (9)
-
Anton Aylward -
Carlos E. R. -
Carlos E. R. -
Carlos E.R.
-
Dave Howorth -
David C. Rankin -
David Haller -
Felix Miata -
Patrick Shanahan