Problems Upgrading from Leap 15.1 to 15.2
I'm following the instructions in SDB:System upgrade, using the zypper method. I've performed the preliminary "Make sure you are up to date" steps successfully, but I'm having problems with the actual update step. Even though I have removed the Packman, Wine and Font repositories from my repository configuration, I'm getting errors relating to components that were installed from those repositories: █ zypper --releasever=15.2 lr -u Warning: Enforced setting: $releasever=15.2 # | Alias | Enabled | GPG Check | Refresh | Priority | URI ---+-------------------------------------+---------+-----------+---------+----------+---------------------------------------------------------------------------------------------- 12 | trinity-noarch | Yes | (r ) Yes | Yes | 97 | http://mirror.ppa.trinitydesktop.org/trinity/trinity/rpm/opensuse15.2/trinit... 13 | trinity-x86_64 | Yes | (r ) Yes | Yes | 97 | http://mirror.ppa.trinitydesktop.org/trinity/trinity/rpm/opensuse15.2/trinit... 1 | http-download.opensuse.org-78e26aa0 | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/update/leap/15.2/oss/ 2 | repo-debug | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/debug/distribution/leap/15.2/repo/oss/ 3 | repo-debug-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/debug/distribution/leap/15.2/repo/non-oss/ 4 | repo-debug-update | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/debug/update/leap/15.2/oss/ 5 | repo-debug-update-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/debug/update/leap/15.2/non-oss/ 6 | repo-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/distribution/leap/15.2/repo/non-oss/ 7 | repo-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/distribution/leap/15.2/repo/oss/ 8 | repo-source | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/source/distribution/leap/15.2/repo/oss/ 9 | repo-source-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/source/distribution/leap/15.2/repo/non-oss/ 10 | repo-update | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/update/leap/15.2/oss 11 | repo-update-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/update/leap/15.2/non-oss/ @06:14:50,root@pinto ~ █ zypper --releasever=15.2 ref Warning: Enforced setting: $releasever=15.2 Retrieving repository 'openSUSE:Leap:15.2:Update' metadata ................................................................................ [done] Building repository 'openSUSE:Leap:15.2:Update' cache ..................................................................................... [done] Repository 'Debug Repository' is up to date. Repository 'Debug Repository (Non-OSS)' is up to date. Repository 'Update Repository (Debug)' is up to date. Repository 'Update Repository (Debug, Non-OSS)' is up to date. Repository 'Non-OSS Repository' is up to date. Repository 'Main Repository' is up to date. Repository 'Source Repository' is up to date. Repository 'Source Repository (Non-OSS)' is up to date. Repository 'Main Update Repository' is up to date. Repository 'Update Repository (Non-Oss)' is up to date. Repository 'trinity-noarch' is up to date. Repository 'trinity-x86_64' is up to date. All repositories have been refreshed. @06:16:24,root@pinto ~ █ zypper --releasever=15.2 dup Warning: Enforced setting: $releasever=15.2 Loading repository data... Reading installed packages... Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Computing distribution upgrade... 118 Problems: Problem: problem with installed package int10h-oldschoolpc-fonts-1.0-lp151.6.1.noarch Problem: problem with installed package libvlc5-3.0.11.1-pm151.6.11.4.x86_64 Problem: problem with installed package libvlccore9-3.0.11.1-pm151.6.11.4.x86_64 Problem: problem with installed package spax-1.6.1-lp151.155.1.x86_64 Problem: problem with installed package star-1.6.1-lp151.155.1.x86_64 Problem: problem with installed package vlc-3.0.11.1-pm151.6.11.4.x86_64 Problem: problem with installed package vlc-codec-gstreamer-3.0.11.1-pm151.6.11.4.x86_64 Problem: problem with installed package vlc-noX-3.0.11.1-pm151.6.11.4.x86_64 Problem: problem with installed package vlc-opencv-3.0.11.1-pm151.6.11.4.x86_64 Problem: problem with installed package vlc-qt-3.0.11.1-pm151.6.11.4.x86_64 Problem: problem with installed package vlc-vdpau-3.0.11.1-pm151.6.11.4.x86_64 Problem: problem with installed package ffmpeg-3-debuginfo-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package ffmpeg-3-debugsource-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package gstreamer-plugins-bad-debuginfo-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package gstreamer-plugins-bad-debugsource-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package gstreamer-plugins-libav-debuginfo-1.12.5-pm151.5.6.x86_64 Problem: problem with installed package gstreamer-plugins-libav-debugsource-1.12.5-pm151.5.6.x86_64 Problem: problem with installed package gstreamer-plugins-ugly-debuginfo-1.12.5-pm151.3.12.x86_64 Problem: problem with installed package gstreamer-plugins-ugly-debugsource-1.12.5-pm151.3.12.x86_64 Problem: problem with installed package libavcodec57-debuginfo-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package libavdevice57-debuginfo-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package libavfilter6-debuginfo-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package libavformat57-debuginfo-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package libavresample3-debuginfo-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package libavutil55-debuginfo-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package libgstadaptivedemux-1_0-0-debuginfo-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package libgstbadaudio-1_0-0-debuginfo-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package libgstbasecamerabinsrc-1_0-0-debuginfo-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package libgstcodecparsers-1_0-0-debuginfo-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package libgstgl-1_0-0-debuginfo-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package libgstmpegts-1_0-0-debuginfo-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package libgstphotography-1_0-0-debuginfo-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package libgsturidownloader-1_0-0-debuginfo-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package libgstwayland-1_0-0-debuginfo-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package libpostproc54-debuginfo-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package libswresample2-debuginfo-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package libswscale4-debuginfo-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package libxine2-debuginfo-1.2.11-pm151.164.1.x86_64 Problem: problem with installed package libxine2-pulse-debuginfo-1.2.11-pm151.164.1.x86_64 Problem: problem with installed package wine-mono-5.1.1-lp151.17.2.noarch Problem: problem with installed package babelstone-modern-fonts-6.002-lp151.6.1.noarch Problem: problem with installed package bitstream-vera-fonts-1.10-lp151.630.1.noarch Problem: problem with installed package cm-unicode-fonts-0.7.0-lp151.385.1.noarch Problem: problem with installed package cpmono_v07-fonts-1.0-lp151.21.1.noarch Problem: problem with installed package cyreal-alice-fonts-1.010-lp151.10.1.noarch Problem: problem with installed package cyreal-lora-fonts-1.014-lp151.11.1.noarch Problem: problem with installed package eb-garamond-fonts-0.016-lp151.5.1.noarch Problem: problem with installed package ffmpeg-3-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package free-ttf-fonts-1.0-lp151.374.1.noarch Problem: problem with installed package gdouros-symbola-fonts-10.23-lp151.32.1.noarch Problem: problem with installed package gdouros-text-fonts-8.01-lp151.9.1.noarch Problem: problem with installed package gdouros-unidings-fonts-9.17-lp151.5.1.noarch Problem: problem with installed package gnu-free-fonts-0.20120503-lp151.28.1.noarch Problem: problem with installed package gnu-unifont-legacy-bitmap-fonts-20080123-lp151.3.1.noarch Problem: problem with installed package gstreamer-plugins-bad-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package gstreamer-plugins-bad-lang-1.12.5-pm151.4.15.noarch Problem: problem with installed package gstreamer-plugins-libav-1.12.5-pm151.5.6.x86_64 Problem: problem with installed package gstreamer-plugins-ugly-1.12.5-pm151.3.12.x86_64 Problem: problem with installed package gstreamer-plugins-ugly-lang-1.12.5-pm151.3.12.noarch Problem: problem with installed package intlfonts-ttf-fonts-1.2.1-lp151.453.1.noarch Problem: problem with installed package intlfonts-type1-fonts-1.2.1-lp151.453.1.noarch Problem: problem with installed package libFAudio0-20.05-lp151.17.1.x86_64 Problem: problem with installed package libFAudio0-32bit-20.05-lp151.17.1.x86_64 Problem: problem with installed package libavcodec57-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package libavcodec58-4.2.1-pm151.2.5.11.x86_64 Problem: problem with installed package libavdevice57-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package libavdevice58-4.2.1-pm151.2.5.11.x86_64 Problem: problem with installed package libavfilter6-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package libavfilter7-4.2.1-pm151.2.5.11.x86_64 Problem: problem with installed package libavformat57-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package libavformat58-4.2.1-pm151.2.5.11.x86_64 Problem: problem with installed package libavresample3-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package libavresample4-4.2.1-pm151.2.5.11.x86_64 Problem: problem with installed package libavutil55-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package libavutil56-4.2.1-pm151.2.5.11.x86_64 Problem: problem with installed package libdav1d3-0.5.2-pm151.7.2.x86_64 Problem: problem with installed package liberation-fonts-1.07.4-lp151.34.1.noarch Problem: problem with installed package libgstadaptivedemux-1_0-0-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package libgstbadaudio-1_0-0-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package libgstbasecamerabinsrc-1_0-0-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package libgstcodecparsers-1_0-0-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package libgstgl-1_0-0-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package libgstmpegts-1_0-0-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package libgstphotography-1_0-0-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package libgsturidownloader-1_0-0-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package libgstwayland-1_0-0-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package libpostproc54-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package libpostproc55-4.2.1-pm151.2.5.11.x86_64 Problem: problem with installed package libquicktime0-1.2.4cvs20150223-pm151.5.14.x86_64 Problem: problem with installed package libswresample2-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package libswresample3-4.2.1-pm151.2.5.11.x86_64 Problem: problem with installed package libswscale4-3.4.8-pm151.2.1.x86_64 Problem: problem with installed package libswscale5-4.2.1-pm151.2.5.11.x86_64 Problem: problem with installed package libxine2-1.2.11-pm151.164.1.x86_64 Problem: problem with installed package libxine2-pulse-1.2.11-pm151.164.1.x86_64 Problem: problem with installed package lomt-blackout-fonts-0.20121218-lp151.14.1.noarch Problem: problem with installed package lomt-chunk-fonts-0.20121218-lp151.14.1.noarch Problem: problem with installed package lomt-fanwood-fonts-0.20121218-lp151.14.1.noarch Problem: problem with installed package lomt-goudybookletter-fonts-0.20121218-lp151.14.1.noarch Problem: problem with installed package lomt-junction-fonts-0.20121218-lp151.14.1.noarch Problem: problem with installed package lomt-knewave-fonts-0.20121218-lp151.14.1.noarch Problem: problem with installed package lomt-leaguegothic-fonts-0.20121218-lp151.14.1.noarch Problem: problem with installed package lomt-lindenhill-fonts-0.20121218-lp151.14.1.noarch Problem: problem with installed package lomt-orbitron-fonts-0.20121218-lp151.14.1.noarch Problem: problem with installed package lomt-ostrichsans-fonts-0.20121218-lp151.14.1.noarch Problem: problem with installed package lomt-prociono-fonts-0.20121218-lp151.14.1.noarch Problem: problem with installed package lomt-script1-fonts-0.20121218-lp151.14.1.noarch Problem: problem with installed package lomt-sniglet-fonts-0.20121218-lp151.14.1.noarch Problem: problem with installed package lomt-sortsmillgoudy-fonts-0.20121218-lp151.14.1.noarch Problem: problem with installed package rmit-sansforgetica-fonts-1.000-lp151.4.1.noarch Problem: problem with installed package sgi-bitmap-fonts-1.0-lp151.1893.1.noarch Problem: problem with installed package terminus-bitmap-fonts-4.48-lp151.37.1.noarch Problem: problem with installed package vollkorn-fonts-4.105-lp151.26.1.noarch Problem: problem with installed package wine-32bit-5.21-lp151.1219.1.x86_64 Problem: problem with installed package wine-5.21-lp151.1219.1.x86_64 Problem: problem with installed package wine-gecko-2.47.1-lp151.57.1.noarch Problem: problem with installed package winetricks-20200412-lp151.25.1.x86_64 Problem: problem with installed package libgstbadvideo-1_0-0-1.12.5-pm151.4.15.x86_64 Problem: problem with installed package int10h-oldschoolpc-fonts-1.0-lp151.6.1.noarch Solution 1: install int10h-oldschoolpc-fonts-2.2-lp152.4.3.1.noarch (with vendor change) obs://build.opensuse.org/M17N --> openSUSE Solution 2: keep obsolete int10h-oldschoolpc-fonts-1.0-lp151.6.1.noarch Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] (c): c How can I bypass these problem packages? Leslie
On 09/01/2021 13.32, J Leslie Turriff wrote:
I'm following the instructions in SDB:System upgrade, using the zypper method. I've performed the preliminary "Make sure you are up to date" steps successfully, but I'm having problems with the actual update step. Even though I have removed the Packman, Wine and Font repositories from my repository configuration, I'm getting errors relating to components that were installed from those repositories:
Certainly. Every repo that you remove will cause problems with packages that were installed from those repos. Thus, for instance, I would never remove packman. Bad idea. Remove only the repositories that you actually want their packages to be switched to the mainline version.
█ zypper --releasever=15.2 lr -u
Don't use "--releasever" with this command, might restrict the information.
Warning: Enforced setting: $releasever=15.2 # | Alias | Enabled | GPG Check | Refresh | Priority | URI ---+-------------------------------------+---------+-----------+---------+----------+---------------------------------------------------------------------------------------------- 12 | trinity-noarch | Yes | (r ) Yes | Yes | 97 | http://mirror.ppa.trinitydesktop.org/trinity/trinity/rpm/opensuse15.2/trinit... 13 | trinity-x86_64 | Yes | (r ) Yes | Yes | 97 | http://mirror.ppa.trinitydesktop.org/trinity/trinity/rpm/opensuse15.2/trinit... 1 | http-download.opensuse.org-78e26aa0 | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/update/leap/15.2/oss/ 2 | repo-debug | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/debug/distribution/leap/15.2/repo/oss/ 3 | repo-debug-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/debug/distribution/leap/15.2/repo/non-oss/
Do you really need the debug repos on?
4 | repo-debug-update | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/debug/update/leap/15.2/oss/ 5 | repo-debug-update-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/debug/update/leap/15.2/non-oss/ 6 | repo-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/distribution/leap/15.2/repo/non-oss/ 7 | repo-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/distribution/leap/15.2/repo/oss/ 8 | repo-source | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/source/distribution/leap/15.2/repo/oss/ 9 | repo-source-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/source/distribution/leap/15.2/repo/non-oss/
Do you really need the source repos on?
10 | repo-update | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/update/leap/15.2/oss 11 | repo-update-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/update/leap/15.2/non-oss/ @06:14:50,root@pinto ~
...
@06:16:24,root@pinto ~ █ zypper --releasever=15.2 dup Warning: Enforced setting: $releasever=15.2
...
Problem: problem with installed package int10h-oldschoolpc-fonts-1.0-lp151.6.1.noarch Solution 1: install int10h-oldschoolpc-fonts-2.2-lp152.4.3.1.noarch (with vendor change) obs://build.opensuse.org/M17N --> openSUSE Solution 2: keep obsolete int10h-oldschoolpc-fonts-1.0-lp151.6.1.noarch
Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] (c): c
How can I bypass these problem packages?
You can't bypass. If your decision was to remove the Font repo, then your next decision has to be #1 above. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Carlos E.R. composed on 2021-01-09 13:43 (UTC+0100):
J Leslie Turriff wrote:
Problem: problem with installed package int10h-oldschoolpc-fonts-1.0-lp151.6.1.noarch Solution 1: install int10h-oldschoolpc-fonts-2.2-lp152.4.3.1.noarch (with vendor change) obs://build.opensuse.org/M17N --> openSUSE Solution 2: keep obsolete int10h-oldschoolpc-fonts-1.0-lp151.6.1.noarch
Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] (c): c
How can I bypass these problem packages?
You can't bypass. If your decision was to remove the Font repo, then your next decision has to be #1 above.
Oh? Fonts aren't distro- or release-specific. What's obsolete is the rpm version string, and maybe new glyphs missing or rendering tweaks missing, which doesn't make those installed unusable or unsafe. I'm still using two decades+ old fonts in most all my installations. Fonts don't really need to be "installed". Fonts can be "installed" by simply copying them to /usr/local/share/fonts/. Then the rpms can be uninstalled to eliminate upgrade process complications. -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2021-01-09 at 15:06 -0500, Felix Miata wrote:
Carlos E.R. composed on 2021-01-09 13:43 (UTC+0100):
J Leslie Turriff wrote:
Problem: problem with installed package int10h-oldschoolpc-fonts-1.0-lp151.6.1.noarch Solution 1: install int10h-oldschoolpc-fonts-2.2-lp152.4.3.1.noarch (with vendor change) obs://build.opensuse.org/M17N --> openSUSE Solution 2: keep obsolete int10h-oldschoolpc-fonts-1.0-lp151.6.1.noarch
Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] (c): c
How can I bypass these problem packages?
You can't bypass. If your decision was to remove the Font repo, then your next decision has to be #1 above.
Oh? Fonts aren't distro- or release-specific. What's obsolete is the rpm version string, and maybe new glyphs missing or rendering tweaks missing, which doesn't make those installed unusable or unsafe. I'm still using two decades+ old fonts in most all my installations.
Fonts don't really need to be "installed". Fonts can be "installed" by simply copying them to /usr/local/share/fonts/. Then the rpms can be uninstalled to eliminate upgrade process complications.
Certainly, but that is irrelevant to the question or the answer :-) I could have written: You can't bypass. If your decision was to remove the XYZ repo, then your next decision has to be: Solution 1: install somepackage-someversion.noarch (with vendor change) obs://build.opensuse.org/XYZ --> openSUSE - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHIEARECADIWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCX/oOQBQccm9iaW4ubGlz dGFzQGdteC5lcwAKCRC1MxgcbY1H1RlaAJ4wMLVgMS2za9Uvoe1ym+4TpY1xqQCf U4xOwiQGeI0HJoiAE8rpS3Q/u/Q= =KbYz -----END PGP SIGNATURE-----
On 2021-01-09 06:43:41 Carlos E.R. wrote:
On 09/01/2021 13.32, J Leslie Turriff wrote:
I'm following the instructions in SDB:System upgrade, using the zypper method. I've performed the preliminary "Make sure you are up to date" steps successfully, but I'm having problems with the actual update step. Even though I have removed the Packman, Wine and Font repositories from my repository configuration, I'm getting errors relating to components that were installed from those repositories:
Certainly. Every repo that you remove will cause problems with packages that were installed from those repos. Thus, for instance, I would never remove packman. Bad idea.
Remove only the repositories that you actually want their packages to be switched to the mainline version.
I guess I misinterpreted the instructions about disabling/enabling repositories to be remove, then add back. I'm not really sure why there would be a difference.
█ zypper --releasever=15.2 lr -u
Don't use "--releasever" with this command, might restrict the information.
I used that to make sure that all of the repositories were in fact using ${releasever} in their definitions.
Warning: Enforced setting: $releasever=15.2 # | Alias | Enabled | GPG Check | Refresh | Priority | URI ---+-------------------------------------+---------+-----------+--------- +----------+-------------------------------------------------------------- -------------------------------- 12 | trinity-noarch | Yes | (r ) Yes | Yes | 97 | http://mirror.ppa.trinitydesktop.org/trinity/trinity/rpm/opensuse15.2/tri nity-r14/RPMS/noarch 13 | trinity-x86_64 | Yes | (r ) Yes | Yes | 97 | http://mirror.ppa.trinitydesktop.org/trinity/trinity/rpm/opensuse15.2/tri nity-r14/RPMS/x86_64 1 | http-download.opensuse.org-78e26aa0 | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/update/leap/15.2/oss/ 2 | repo-debug | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/debug/distribution/leap/15.2/repo/oss/ 3 | repo-debug-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/debug/distribution/leap/15.2/repo/non-oss/
Do you really need the debug repos on?
4 | repo-debug-update | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/debug/update/leap/15.2/oss/ 5 | repo-debug-update-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/debug/update/leap/15.2/non-oss/ 6 | repo-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/distribution/leap/15.2/repo/non-oss/ 7 | repo-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/distribution/leap/15.2/repo/oss/ 8 | repo-source | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/source/distribution/leap/15.2/repo/oss/ 9 | repo-source-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/source/distribution/leap/15.2/repo/non-oss/
Do you really need the source repos on?
10 | repo-update | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/update/leap/15.2/oss 11 | repo-update-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/update/leap/15.2/non-oss/ @06:14:50,root@pinto ~
...
@06:16:24,root@pinto ~ █ zypper --releasever=15.2 dup Warning: Enforced setting: $releasever=15.2
...
Problem: problem with installed package int10h-oldschoolpc-fonts-1.0-lp151.6.1.noarch Solution 1: install int10h-oldschoolpc-fonts-2.2-lp152.4.3.1.noarch (with vendor change) obs://build.opensuse.org/M17N --> openSUSE Solution 2: keep obsolete int10h-oldschoolpc-fonts-1.0-lp151.6.1.noarch
Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] (c): c
How can I bypass these problem packages?
You can't bypass. If your decision was to remove the Font repo, then your next decision has to be #1 above.
I will add the missing repositories to my setup again, and start over. Leslie --
On Sat, 9 Jan 2021 23:09:28 -0600
J Leslie Turriff
On 2021-01-09 06:43:41 Carlos E.R. wrote:
On 09/01/2021 13.32, J Leslie Turriff wrote:
I'm following the instructions in SDB:System upgrade, using the zypper method. I've performed the preliminary "Make sure you are up to date" steps successfully, but I'm having problems with the actual update step. Even though I have removed the Packman, Wine and Font repositories from my repository configuration, I'm getting errors relating to components that were installed from those repositories:
Certainly. Every repo that you remove will cause problems with packages that were installed from those repos. Thus, for instance, I would never remove packman. Bad idea.
Remove only the repositories that you actually want their packages to be switched to the mainline version.
I guess I misinterpreted the instructions about disabling/enabling repositories to be remove, then add back. I'm not really sure why there would be a difference.
No, I think you interpreted them correctly. I think the question is why the wiki says that?
█ zypper --releasever=15.2 lr -u
Don't use "--releasever" with this command, might restrict the information. I used that to make sure that all of the repositories were in fact using ${releasever} in their definitions.
Warning: Enforced setting: $releasever=15.2 # | Alias | Enabled | GPG Check | Refresh | Priority | URI ---+-------------------------------------+---------+-----------+--------- +----------+-------------------------------------------------------------- -------------------------------- 12 | trinity-noarch | Yes | (r ) Yes | Yes | 97 | http://mirror.ppa.trinitydesktop.org/trinity/trinity/rpm/opensuse15.2/tri nity-r14/RPMS/noarch 13 | trinity-x86_64 | Yes | (r ) Yes | Yes | 97 | http://mirror.ppa.trinitydesktop.org/trinity/trinity/rpm/opensuse15.2/tri nity-r14/RPMS/x86_64 1 | http-download.opensuse.org-78e26aa0 | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/update/leap/15.2/oss/ 2 | repo-debug | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/debug/distribution/leap/15.2/repo/oss/ 3 | repo-debug-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/debug/distribution/leap/15.2/repo/non-oss/
Do you really need the debug repos on?
4 | repo-debug-update | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/debug/update/leap/15.2/oss/ 5 | repo-debug-update-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/debug/update/leap/15.2/non-oss/ 6 | repo-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/distribution/leap/15.2/repo/non-oss/ 7 | repo-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/distribution/leap/15.2/repo/oss/ 8 | repo-source | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/source/distribution/leap/15.2/repo/oss/ 9 | repo-source-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/source/distribution/leap/15.2/repo/non-oss/
Do you really need the source repos on?
10 | repo-update | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/update/leap/15.2/oss 11 | repo-update-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/update/leap/15.2/non-oss/ @06:14:50,root@pinto ~
...
@06:16:24,root@pinto ~ █ zypper --releasever=15.2 dup Warning: Enforced setting: $releasever=15.2
...
Problem: problem with installed package int10h-oldschoolpc-fonts-1.0-lp151.6.1.noarch Solution 1: install int10h-oldschoolpc-fonts-2.2-lp152.4.3.1.noarch (with vendor change) obs://build.opensuse.org/M17N --> openSUSE Solution 2: keep obsolete int10h-oldschoolpc-fonts-1.0-lp151.6.1.noarch
Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] (c): c
How can I bypass these problem packages?
You can't bypass. If your decision was to remove the Font repo, then your next decision has to be #1 above.
I will add the missing repositories to my setup again, and start over.
Leslie
On 10/01/2021 10.28, Dave Howorth wrote:
On Sat, 9 Jan 2021 23:09:28 -0600 J Leslie Turriff <> wrote:
...
No, I think you interpreted them correctly. I think the question is why the wiki says that? Maybe because "allow vendor change" was implicitly the default. The feature to try to keep the packages in the same repo was added later to "zypper dup", and this caused upgrades to get unexpected results when upgrading with several repos active.
For example, packages from repo A could be switched to repos B, C, and D if they had newer versions, breaking consistency. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 10/01/2021 14.28, Carlos E. R. wrote:
On 10/01/2021 10.28, Dave Howorth wrote:
On Sat, 9 Jan 2021 23:09:28 -0600 J Leslie Turriff <> wrote:
...
No, I think you interpreted them correctly. I think the question is why the wiki says that? Maybe because "allow vendor change" was implicitly the default. The feature to try to keep the packages in the same repo was added later to "zypper dup", and this caused upgrades to get unexpected results when upgrading with several repos active.
I mean that previously, not keeping vendor, caused upgrades to... Wasn't clear.
For example, packages from repo A could be switched to repos B, C, and D if they had newer versions, breaking consistency.
-- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 10/01/2021 06.09, J Leslie Turriff wrote:
On 2021-01-09 06:43:41 Carlos E.R. wrote:
On 09/01/2021 13.32, J Leslie Turriff wrote:
I'm following the instructions in SDB:System upgrade, using the zypper method. I've performed the preliminary "Make sure you are up to date" steps successfully, but I'm having problems with the actual update step. Even though I have removed the Packman, Wine and Font repositories from my repository configuration, I'm getting errors relating to components that were installed from those repositories:
Certainly. Every repo that you remove will cause problems with packages that were installed from those repos. Thus, for instance, I would never remove packman. Bad idea.
Remove only the repositories that you actually want their packages to be switched to the mainline version.
I guess I misinterpreted the instructions about disabling/enabling repositories to be remove, then add back. I'm not really sure why there would be a difference.
The instructions lag behind the progress of features in the software. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-10 05:01:55 Carlos E. R. wrote:
On 10/01/2021 06.09, J Leslie Turriff wrote:
On 2021-01-09 06:43:41 Carlos E.R. wrote:
On 09/01/2021 13.32, J Leslie Turriff wrote:
I'm following the instructions in SDB:System upgrade, using the zypper method. I've performed the preliminary "Make sure you are up to date" steps successfully, but I'm having problems with the actual update step. Even though I have removed the Packman, Wine and Font repositories from my repository configuration, I'm getting errors relating to components that were installed from those repositories:
Certainly. Every repo that you remove will cause problems with packages that were installed from those repos. Thus, for instance, I would never remove packman. Bad idea.
Remove only the repositories that you actually want their packages to be switched to the mainline version.
I guess I misinterpreted the instructions about disabling/enabling repositories to be remove, then add back. I'm not really sure why there would be a difference.
The instructions lag behind the progress of features in the software.
The instructions should be updated at the time features in the software change, otherwise they are worse than useless. Leslie --
On 10/01/2021 12.17, J Leslie Turriff wrote:
On 2021-01-10 05:01:55 Carlos E. R. wrote:
On 10/01/2021 06.09, J Leslie Turriff wrote:
On 2021-01-09 06:43:41 Carlos E.R. wrote:
On 09/01/2021 13.32, J Leslie Turriff wrote:
I'm following the instructions in SDB:System upgrade, using the zypper method. I've performed the preliminary "Make sure you are up to date" steps successfully, but I'm having problems with the actual update step. Even though I have removed the Packman, Wine and Font repositories from my repository configuration, I'm getting errors relating to components that were installed from those repositories:
Certainly. Every repo that you remove will cause problems with packages that were installed from those repos. Thus, for instance, I would never remove packman. Bad idea.
Remove only the repositories that you actually want their packages to be switched to the mainline version.
I guess I misinterpreted the instructions about disabling/enabling repositories to be remove, then add back. I'm not really sure why there would be a difference.
The instructions lag behind the progress of features in the software.
The instructions should be updated at the time features in the software change, otherwise they are worse than useless.
But those instructions are written by volunteers, typically users, not the developers that created the features. Volunteers find out the new features after finding them (by chance sometimes) and using them, experiencing them. There has to be a delay and missed features. For instance, I wrote most of the other wiki page on the DVD upgrade method. The page needs updating, but the problem is, that these days I'm not using the DVD method because it doesn't work on some of my machines, so I don't have the current experience. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 10/01/2021 12.30, Carlos E. R. wrote:
On 10/01/2021 12.17, J Leslie Turriff wrote:
On 2021-01-10 05:01:55 Carlos E. R. wrote:
On 10/01/2021 06.09, J Leslie Turriff wrote:
On 2021-01-09 06:43:41 Carlos E.R. wrote:
On 09/01/2021 13.32, J Leslie Turriff wrote:
I'm following the instructions in SDB:System upgrade, using the zypper method. I've performed the preliminary "Make sure you are up to date" steps successfully, but I'm having problems with the actual update step. Even though I have removed the Packman, Wine and Font repositories from my repository configuration, I'm getting errors relating to components that were installed from those repositories:
Certainly. Every repo that you remove will cause problems with packages that were installed from those repos. Thus, for instance, I would never remove packman. Bad idea.
Remove only the repositories that you actually want their packages to be switched to the mainline version.
I guess I misinterpreted the instructions about disabling/enabling repositories to be remove, then add back. I'm not really sure why there would be a difference.
The instructions lag behind the progress of features in the software.
The instructions should be updated at the time features in the software change, otherwise they are worse than useless.
But those instructions are written by volunteers, typically users, not the developers that created the features. Volunteers find out the new features after finding them (by chance sometimes) and using them, experiencing them. There has to be a delay and missed features.
For instance, I wrote most of the other wiki page on the DVD upgrade method. The page needs updating, but the problem is, that these days I'm not using the DVD method because it doesn't work on some of my machines, so I don't have the current experience.
Ok, I have added a new section on this. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-10 05:30:25 Carlos E. R. wrote:
On 10/01/2021 12.17, J Leslie Turriff wrote:
On 2021-01-10 05:01:55 Carlos E. R. wrote:
On 10/01/2021 06.09, J Leslie Turriff wrote:
On 2021-01-09 06:43:41 Carlos E.R. wrote:
On 09/01/2021 13.32, J Leslie Turriff wrote:
I'm following the instructions in SDB:System upgrade, using the zypper method. I've performed the preliminary "Make sure you are up to date" steps successfully, but I'm having problems with the actual update step. Even though I have removed the Packman, Wine and Font repositories from my repository configuration, I'm getting errors relating to components that were installed from those repositories:
Certainly. Every repo that you remove will cause problems with packages that were installed from those repos. Thus, for instance, I would never remove packman. Bad idea.
Remove only the repositories that you actually want their packages to be switched to the mainline version.
I guess I misinterpreted the instructions about disabling/enabling repositories to be remove, then add back. I'm not really sure why there would be a difference.
The instructions lag behind the progress of features in the software.
The instructions should be updated at the time features in the software change, otherwise they are worse than useless.
But those instructions are written by volunteers, typically users, not the developers that created the features. Volunteers find out the new features after finding them (by chance sometimes) and using them, experiencing them. There has to be a delay and missed features.
For instance, I wrote most of the other wiki page on the DVD upgrade method. The page needs updating, but the problem is, that these days I'm not using the DVD method because it doesn't work on some of my machines, so I don't have the current experience.
I see. So the standard practice in the *nix community is to make changes to software that performs critical operations, without providing any notice to the community that their changes will negatively affect. (A system upgrade, IMO, is something that will possibly brick a machine if the instructions for using the upgrade tools do not match the reality of the software's operation.) So upgrading my system is a matter of proceeding 'on a wing and a prayer. Leslie --
On 11/01/2021 04.49, J Leslie Turriff wrote:
On 2021-01-10 05:30:25 Carlos E. R. wrote:
On 10/01/2021 12.17, J Leslie Turriff wrote:
On 2021-01-10 05:01:55 Carlos E. R. wrote:
On 10/01/2021 06.09, J Leslie Turriff wrote:
On 2021-01-09 06:43:41 Carlos E.R. wrote:
On 09/01/2021 13.32, J Leslie Turriff wrote: > I'm following the instructions in SDB:System upgrade, using the > zypper method. I've performed the preliminary "Make sure you are up > to date" steps successfully, but I'm having problems with the actual > update step. Even though I have removed the Packman, Wine and Font > repositories from my repository configuration, I'm getting errors > relating to components that were installed from those repositories:
Certainly. Every repo that you remove will cause problems with packages that were installed from those repos. Thus, for instance, I would never remove packman. Bad idea.
Remove only the repositories that you actually want their packages to be switched to the mainline version.
I guess I misinterpreted the instructions about disabling/enabling repositories to be remove, then add back. I'm not really sure why there would be a difference.
The instructions lag behind the progress of features in the software.
The instructions should be updated at the time features in the software change, otherwise they are worse than useless.
But those instructions are written by volunteers, typically users, not the developers that created the features. Volunteers find out the new features after finding them (by chance sometimes) and using them, experiencing them. There has to be a delay and missed features.
For instance, I wrote most of the other wiki page on the DVD upgrade method. The page needs updating, but the problem is, that these days I'm not using the DVD method because it doesn't work on some of my machines, so I don't have the current experience.
I see. So the standard practice in the *nix community is to make changes to software that performs critical operations, without providing any notice to the community that their changes will negatively affect. (A system upgrade, IMO, is something that will possibly brick a machine if the instructions for using the upgrade tools do not match the reality of the software's operation.) So upgrading my system is a matter of proceeding 'on a wing and a prayer.
Well, I have been upgrading my main system for close to 20 years, version after version. I am here :-) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-11 05:33:12 Carlos E. R. wrote:
On 11/01/2021 04.49, J Leslie Turriff wrote:
On 2021-01-10 05:30:25 Carlos E. R. wrote:
On 10/01/2021 12.17, J Leslie Turriff wrote:
On 2021-01-10 05:01:55 Carlos E. R. wrote:
On 10/01/2021 06.09, J Leslie Turriff wrote:
On 2021-01-09 06:43:41 Carlos E.R. wrote: > On 09/01/2021 13.32, J Leslie Turriff wrote: >> I'm following the instructions in SDB:System upgrade, using the >> zypper method. I've performed the preliminary "Make sure you are >> up to date" steps successfully, but I'm having problems with the >> actual update step. Even though I have removed the Packman, Wine >> and Font repositories from my repository configuration, I'm getting >> errors relating to components that were installed from those >> repositories: > > Certainly. Every repo that you remove will cause problems with > packages that were installed from those repos. Thus, for instance, I > would never remove packman. Bad idea. > > Remove only the repositories that you actually want their packages > to be switched to the mainline version.
I guess I misinterpreted the instructions about disabling/enabling repositories to be remove, then add back. I'm not really sure why there would be a difference.
The instructions lag behind the progress of features in the software.
The instructions should be updated at the time features in the software change, otherwise they are worse than useless.
But those instructions are written by volunteers, typically users, not the developers that created the features. Volunteers find out the new features after finding them (by chance sometimes) and using them, experiencing them. There has to be a delay and missed features.
For instance, I wrote most of the other wiki page on the DVD upgrade method. The page needs updating, but the problem is, that these days I'm not using the DVD method because it doesn't work on some of my machines, so I don't have the current experience.
I see. So the standard practice in the *nix community is to make changes to software that performs critical operations, without providing any notice to the community that their changes will negatively affect. (A system upgrade, IMO, is something that will possibly brick a machine if the instructions for using the upgrade tools do not match the reality of the software's operation.) So upgrading my system is a matter of proceeding 'on a wing and a prayer.
Well, I have been upgrading my main system for close to 20 years, version after version. I am here :-)
That's nice. This is my first attempt to break away from clean reinstalls, which entails laboriously finding and reinstalling supplementary tools after installing the base system. Leslie --
On 12/01/2021 03.08, J Leslie Turriff wrote:
On 2021-01-11 05:33:12 Carlos E. R. wrote:
On 11/01/2021 04.49, J Leslie Turriff wrote:
On 2021-01-10 05:30:25 Carlos E. R. wrote:
On 10/01/2021 12.17, J Leslie Turriff wrote:
On 2021-01-10 05:01:55 Carlos E. R. wrote:
On 10/01/2021 06.09, J Leslie Turriff wrote: > On 2021-01-09 06:43:41 Carlos E.R. wrote: >> On 09/01/2021 13.32, J Leslie Turriff wrote: >>> I'm following the instructions in SDB:System upgrade, using the >>> zypper method. I've performed the preliminary "Make sure you are >>> up to date" steps successfully, but I'm having problems with the >>> actual update step. Even though I have removed the Packman, Wine >>> and Font repositories from my repository configuration, I'm getting >>> errors relating to components that were installed from those >>> repositories: >> >> Certainly. Every repo that you remove will cause problems with >> packages that were installed from those repos. Thus, for instance, I >> would never remove packman. Bad idea. >> >> Remove only the repositories that you actually want their packages >> to be switched to the mainline version. > > I guess I misinterpreted the instructions about disabling/enabling > repositories to be remove, then add back. I'm not really sure why > there would be a difference.
The instructions lag behind the progress of features in the software.
The instructions should be updated at the time features in the software change, otherwise they are worse than useless.
But those instructions are written by volunteers, typically users, not the developers that created the features. Volunteers find out the new features after finding them (by chance sometimes) and using them, experiencing them. There has to be a delay and missed features.
For instance, I wrote most of the other wiki page on the DVD upgrade method. The page needs updating, but the problem is, that these days I'm not using the DVD method because it doesn't work on some of my machines, so I don't have the current experience.
I see. So the standard practice in the *nix community is to make changes to software that performs critical operations, without providing any notice to the community that their changes will negatively affect. (A system upgrade, IMO, is something that will possibly brick a machine if the instructions for using the upgrade tools do not match the reality of the software's operation.) So upgrading my system is a matter of proceeding 'on a wing and a prayer.
Well, I have been upgrading my main system for close to 20 years, version after version. I am here :-)
That's nice. This is my first attempt to break away from clean reinstalls, which entails laboriously finding and reinstalling supplementary tools after installing the base system.
Huh? What supplementary tools did you have to install? -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-11 22:06:03 Carlos E. R. wrote:
On 12/01/2021 03.08, J Leslie Turriff wrote:
On 2021-01-11 05:33:12 Carlos E. R. wrote:
On 11/01/2021 04.49, J Leslie Turriff wrote:
On 2021-01-10 05:30:25 Carlos E. R. wrote:
On 10/01/2021 12.17, J Leslie Turriff wrote:
On 2021-01-10 05:01:55 Carlos E. R. wrote: > On 10/01/2021 06.09, J Leslie Turriff wrote: >> On 2021-01-09 06:43:41 Carlos E.R. wrote: >>> On 09/01/2021 13.32, J Leslie Turriff wrote: >>>> I'm following the instructions in SDB:System upgrade, using the >>>> zypper method. I've performed the preliminary "Make sure you are >>>> up to date" steps successfully, but I'm having problems with the >>>> actual update step. Even though I have removed the Packman, Wine >>>> and Font repositories from my repository configuration, I'm >>>> getting errors relating to components that were installed from >>>> those repositories: >>> >>> Certainly. Every repo that you remove will cause problems with >>> packages that were installed from those repos. Thus, for instance, >>> I would never remove packman. Bad idea. >>> >>> Remove only the repositories that you actually want their packages >>> to be switched to the mainline version. >> >> I guess I misinterpreted the instructions about disabling/enabling >> repositories to be remove, then add back. I'm not really sure why >> there would be a difference. > > The instructions lag behind the progress of features in the > software.
The instructions should be updated at the time features in the software change, otherwise they are worse than useless.
But those instructions are written by volunteers, typically users, not the developers that created the features. Volunteers find out the new features after finding them (by chance sometimes) and using them, experiencing them. There has to be a delay and missed features.
For instance, I wrote most of the other wiki page on the DVD upgrade method. The page needs updating, but the problem is, that these days I'm not using the DVD method because it doesn't work on some of my machines, so I don't have the current experience.
I see. So the standard practice in the *nix community is to make changes to software that performs critical operations, without providing any notice to the community that their changes will negatively affect. (A system upgrade, IMO, is something that will possibly brick a machine if the instructions for using the upgrade tools do not match the reality of the software's operation.) So upgrading my system is a matter of proceeding 'on a wing and a prayer.
Well, I have been upgrading my main system for close to 20 years, version after version. I am here :-)
That's nice. This is my first attempt to break away from clean reinstalls, which entails laboriously finding and reinstalling supplementary tools after installing the base system.
Huh? What supplementary tools did you have to install?
I mean all of the things that I use that aren't part of the pattern bases. Leslie --
On 12/01/2021 06.54, J Leslie Turriff wrote:
On 2021-01-11 22:06:03 Carlos E. R. wrote:
On 12/01/2021 03.08, J Leslie Turriff wrote:
On 2021-01-11 05:33:12 Carlos E. R. wrote:
...
Well, I have been upgrading my main system for close to 20 years, version after version. I am here :-)
That's nice. This is my first attempt to break away from clean reinstalls, which entails laboriously finding and reinstalling supplementary tools after installing the base system.
Huh? What supplementary tools did you have to install?
I mean all of the things that I use that aren't part of the pattern bases.
Ah, you mean that you turned to upgrades so as not to have to reinstall again those "extras". Yes, of course, so say we all ;-) That and redoing all the system configs. But the caveat is that the proces itself has some more complications that a reinstall. Still, the benefits (for me) surpass the complications. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Sun, 10 Jan 2021 21:49:32 -0600
J Leslie Turriff
On 2021-01-10 05:30:25 Carlos E. R. wrote:
On 10/01/2021 12.17, J Leslie Turriff wrote:
On 2021-01-10 05:01:55 Carlos E. R. wrote:
On 10/01/2021 06.09, J Leslie Turriff wrote:
On 2021-01-09 06:43:41 Carlos E.R. wrote:
On 09/01/2021 13.32, J Leslie Turriff wrote: > I'm following the instructions in SDB:System upgrade, > using the zypper method. I've performed the preliminary > "Make sure you are up to date" steps successfully, but I'm > having problems with the actual update step. Even though I > have removed the Packman, Wine and Font repositories from my > repository configuration, I'm getting errors relating to > components that were installed from those repositories:
Certainly. Every repo that you remove will cause problems with packages that were installed from those repos. Thus, for instance, I would never remove packman. Bad idea.
Remove only the repositories that you actually want their packages to be switched to the mainline version.
I guess I misinterpreted the instructions about disabling/enabling repositories to be remove, then add back. I'm not really sure why there would be a difference.
The instructions lag behind the progress of features in the software.
The instructions should be updated at the time features in the software change, otherwise they are worse than useless.
But those instructions are written by volunteers, typically users, not the developers that created the features. Volunteers find out the new features after finding them (by chance sometimes) and using them, experiencing them. There has to be a delay and missed features.
For instance, I wrote most of the other wiki page on the DVD upgrade method. The page needs updating, but the problem is, that these days I'm not using the DVD method because it doesn't work on some of my machines, so I don't have the current experience.
I see. So the standard practice in the *nix community
Not all *nix, no. Commercial Unix suppliers tend to keep their documentation in better order, because the law constrains them in some respects to have accurate documentation and they have paid developers and paid documenters. Community-run Linux distros OTOH have volunteer labour for pretty much everything and volunteers can be picky about what they do. I would guess, but I do not know, that the SLES upgrade instructions are more consistent. E.g.: https://documentation.suse.com/sles/15-SP1/single-html/SLES-upgrade/index.ht...
is to make changes to software that performs critical operations, without providing any notice to the community that their changes will negatively affect. (A system upgrade, IMO, is something that will possibly brick a machine if the instructions for using the upgrade tools do not match the reality of the software's operation.) So upgrading my system is a matter of proceeding 'on a wing and a prayer.
That's why people suggest taking regular backups, especially also before upgrades or other system changes, and is one of the reasons for multi-version support of kernels and why the system uses BTRFS snapshots before and after upgrades and software changes.
Leslie --
J Leslie Turriff composed on 2021-01-10 05:17 (UTC-0600):
Carlos E. R. wrote:
The instructions lag behind the progress of features in the software.
The instructions should be updated at the time features in the software change, otherwise they are worse than useless.
Sure they should be, but the creators of the changes are rarely involved in updating SDB pages. Writing documentation is a talent of its own which coders may not have. I tend to think few have any of such talent, and those that do get paid for that talent instead of giving it away. -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
On 2021-01-10 05:38:11 Felix Miata wrote:
J Leslie Turriff composed on 2021-01-10 05:17 (UTC-0600):
Carlos E. R. wrote:
The instructions lag behind the progress of features in the software.
The instructions should be updated at the time features in the software change, otherwise they are worse than useless.
Sure they should be, but the creators of the changes are rarely involved in updating SDB pages. Writing documentation is a talent of its own which coders may not have. I tend to think few have any of such talent, and those that do get paid for that talent instead of giving it away.
I'm sorry; for normal application software that might be considered reasonable, but not for something as critical as system upgrade software, there should be at least some sort of 'heads-up' notification of changes. Leslie --
J Leslie Turriff composed on 2021-01-10 21:51 (UTC-0600):
Felix Miata wrote:
Sure they should be, but the creators of the changes are rarely involved in updating SDB pages. Writing documentation is a talent of its own which coders may not have. I tend to think few have any of such talent, and those that do get paid for that talent instead of giving it away.
I'm sorry; for normal application software that might be considered reasonable, but not for something as critical as system upgrade software, there should be at least some sort of 'heads-up' notification of changes.
Did you look in official documentation first? You may have it installed. If not: https://doc.opensuse.org/documentation/leap/reference/single-html/book-opens... SDBs are typically created and maintained by mere mortal users under no obligation to know what such a doc should contain, or its accuracy or relevance. You may be jaded by the stability of TDE. ;) -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
On 2021-01-10 22:30:37 Felix Miata wrote:
J Leslie Turriff composed on 2021-01-10 21:51 (UTC-0600):
Felix Miata wrote:
Sure they should be, but the creators of the changes are rarely involved in updating SDB pages. Writing documentation is a talent of its own which coders may not have. I tend to think few have any of such talent, and those that do get paid for that talent instead of giving it away.
I'm sorry; for normal application software that might be considered reasonable, but not for something as critical as system upgrade software, there should be at least some sort of 'heads-up' notification of changes.
Did you look in official documentation first? You may have it installed. If not: <https://doc.opensuse.org/documentation/leap/reference/single-html/book-ope nsuse-reference/index.html#part-reference-adv-admin>
SDBs are typically created and maintained by mere mortal users under no obligation to know what such a doc should contain, or its accuracy or relevance.
You may be jaded by the stability of TDE. ;)
:-D I admit that I'm jaded by the extensive, comprehensive documentation that I used as a systems administrator of IBM mainframe systems. Leslie --
On 10/01/2021 06.09, J Leslie Turriff wrote:
On 2021-01-09 06:43:41 Carlos E.R. wrote:
...
You can't bypass. If your decision was to remove the Font repo, then your next decision has to be #1 above.
I will add the missing repositories to my setup again, and start over.
Notice that there are cases when you really want to remove a repository. Say you added a repository at some point to get a new version of a package because it solved a bug, but now that you update the whole distribution you want to go back to the stock version. It is your decision what to do. With fewer repos is easier to maintain your machine, so taking the occasion of a distribution upgrade to remove some, is a good idea. For example, I disabled the XFCE repo on distro upgrade (not removed). -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-10 05:24:15 Carlos E.R. wrote:
On 10/01/2021 06.09, J Leslie Turriff wrote:
On 2021-01-09 06:43:41 Carlos E.R. wrote:
...
You can't bypass. If your decision was to remove the Font repo, then your next decision has to be #1 above.
I will add the missing repositories to my setup again, and start over.
Notice that there are cases when you really want to remove a repository. Say you added a repository at some point to get a new version of a package because it solved a bug, but now that you update the whole distribution you want to go back to the stock version.
It is your decision what to do. With fewer repos is easier to maintain your machine, so taking the occasion of a distribution upgrade to remove some, is a good idea.
For example, I disabled the XFCE repo on distro upgrade (not removed).
Considering the sensitivity of a software tool like zypper, my opinion is that its documentation is far too sketchy and vague. Today, partway through my upgrade I received a warning for a library whose signature did not match its checksum; the actions for proceeding were 'Abort, Retry, Ignore'. Not wanting to abort my upgrade, I guessed that 'Ignore' would be the appropriate response, but my guess was wrong, and zypper proceeded to install the faulty library. A much better prompt would have been 'Discard, Retry, Install', not the ambiguous 'Abort, Retry, Ignore'. Of course, there is nothing in the man page for zypper that discusses these sort of prompts, so in the middle of performing a critical operation on the system, one has to guess what the prompt means. Leslie --
On 11/01/2021 04.56, J Leslie Turriff wrote:
On 2021-01-10 05:24:15 Carlos E.R. wrote:
On 10/01/2021 06.09, J Leslie Turriff wrote:
On 2021-01-09 06:43:41 Carlos E.R. wrote:
...
You can't bypass. If your decision was to remove the Font repo, then your next decision has to be #1 above.
I will add the missing repositories to my setup again, and start over.
Notice that there are cases when you really want to remove a repository. Say you added a repository at some point to get a new version of a package because it solved a bug, but now that you update the whole distribution you want to go back to the stock version.
It is your decision what to do. With fewer repos is easier to maintain your machine, so taking the occasion of a distribution upgrade to remove some, is a good idea.
For example, I disabled the XFCE repo on distro upgrade (not removed).
Considering the sensitivity of a software tool like zypper, my opinion is that its documentation is far too sketchy and vague. Today, partway through my upgrade I received a warning for a library whose signature did not match its checksum; the actions for proceeding were 'Abort, Retry, Ignore'. Not wanting to abort my upgrade, I guessed that 'Ignore' would be the appropriate response, but my guess was wrong, and zypper proceeded to install the faulty library.
Well, ignore means ignore the error and continue. That is, continue installing it. Retry tries to download it again, that is the correct option. Abort aborts the entire zypper command, which can be very bad in mid upgrade. There is no option to "skip" the package. What I do is "retry", if it happens again then "ignore", and take down a note to do again that package at the end or another day.
A much better prompt would have been 'Discard, Retry, Install', not the ambiguous 'Abort, Retry, Ignore'. Of course, there is nothing in the man page for zypper that discusses these sort of prompts, so in the middle of performing a critical operation on the system, one has to guess what the prompt means.
You are free to report in bugzilla ;-) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-09 23:09:28 J Leslie Turriff wrote:
On 2021-01-09 06:43:41 Carlos E.R. wrote:
On 09/01/2021 13.32, J Leslie Turriff wrote:
I'm following the instructions in SDB:System upgrade, using the zypper method. I've performed the preliminary "Make sure you are up to date" steps successfully, but I'm having problems with the actual update step. Even though I have removed the Packman, Wine and Font repositories from my repository configuration, I'm getting errors relating to components that were installed from those repositories:
Certainly. Every repo that you remove will cause problems with packages that were installed from those repos. Thus, for instance, I would never remove packman. Bad idea.
Remove only the repositories that you actually want their packages to be switched to the mainline version.
I guess I misinterpreted the instructions about disabling/enabling repositories to be remove, then add back. I'm not really sure why there would be a difference.
█ zypper --releasever=15.2 lr -u
Don't use "--releasever" with this command, might restrict the information.
I used that to make sure that all of the repositories were in fact using ${releasever} in their definitions.
Warning: Enforced setting: $releasever=15.2 # | Alias | Enabled | GPG Check | Refresh
| Priority | URI
---+-------------------------------------+---------+-----------+------- -- +----------+----------------------------------------------------------- --- -------------------------------- 12 | trinity-noarch
| Yes | (r ) Yes | Yes | 97 |
http://mirror.ppa.trinitydesktop.org/trinity/trinity/rpm/opensuse15.2/t ri nity-r14/RPMS/noarch 13 | trinity-x86_64 | Yes | (r ) Yes | Yes | 97 | http://mirror.ppa.trinitydesktop.org/trinity/trinity/rpm/opensuse15.2/t ri nity-r14/RPMS/x86_64 1 | http-download.opensuse.org-78e26aa0 | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/update/leap/15.2/oss/ 2 | repo-debug
| Yes | (r ) Yes | Yes | 99 |
http://download.opensuse.org/debug/distribution/leap/15.2/repo/oss/ 3 | repo-debug-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/debug/distribution/leap/15.2/repo/non-oss/
Do you really need the debug repos on?
4 | repo-debug-update | Yes | (r ) Yes | Yes
| 99 | http://download.opensuse.org/debug/update/leap/15.2/oss/ | 5 repo-debug-update-non-oss | Yes | (r ) Yes | Yes | |
99 | http://download.opensuse.org/debug/update/leap/15.2/non-oss/ 6
| repo-non-oss | Yes | (r ) Yes | Yes |
99 | http://download.opensuse.org/distribution/leap/15.2/repo/non-oss/ 7 | repo-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/distribution/leap/15.2/repo/oss/ 8
| repo-source | Yes | (r ) Yes | Yes |
99 | http://download.opensuse.org/source/distribution/leap/15.2/repo/oss/ 9 | repo-source-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/source/distribution/leap/15.2/repo/non-oss /
Do you really need the source repos on?
10 | repo-update | Yes | (r ) Yes | Yes
| 99 | http://download.opensuse.org/update/leap/15.2/oss 11 |
repo-update-non-oss | Yes | (r ) Yes | Yes | 99 | http://download.opensuse.org/update/leap/15.2/non-oss/ @06:14:50,root@pinto ~
...
@06:16:24,root@pinto ~ █ zypper --releasever=15.2 dup Warning: Enforced setting: $releasever=15.2
...
Problem: problem with installed package int10h-oldschoolpc-fonts-1.0-lp151.6.1.noarch Solution 1: install int10h-oldschoolpc-fonts-2.2-lp152.4.3.1.noarch (with vendor change) obs://build.opensuse.org/M17N --> openSUSE Solution 2: keep obsolete int10h-oldschoolpc-fonts-1.0-lp151.6.1.noarch
Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] (c): c
How can I bypass these problem packages?
You can't bypass. If your decision was to remove the Font repo, then your next decision has to be #1 above.
I will add the missing repositories to my setup again, and start over.
Leslie
So, after downloading 9313 components the process stopped with this message (last three lines): | Retrieving package patterns-gnome-gnome_basis_opt-20180321-lp152.7.3.x86_64 (9313/9313), 16.0 KiB ( 61 B unpacked) | Retrieving: patterns-gnome-gnome_basis_opt-20180321-lp152.7.3.x86_64.rpm ...................................................... [done (1.8 KiB/s)] | Installation has completed with error. Unlike installation of individual packages, there are no messages about installing the downloaded RPMs. What should I conclude about this? Leslie --
On 11/01/2021 07.16, J Leslie Turriff wrote:
On 2021-01-09 23:09:28 J Leslie Turriff wrote:
On 2021-01-09 06:43:41 Carlos E.R. wrote:
On 09/01/2021 13.32, J Leslie Turriff wrote:
...
So, after downloading 9313 components the process stopped with this message (last three lines): | Retrieving package patterns-gnome-gnome_basis_opt-20180321-lp152.7.3.x86_64 (9313/9313), 16.0 KiB ( 61 B unpacked) | Retrieving: patterns-gnome-gnome_basis_opt-20180321-lp152.7.3.x86_64.rpm ...................................................... [done (1.8 KiB/s)] | Installation has completed with error.
Unlike installation of individual packages, there are no messages about installing the downloaded RPMs. What should I conclude about this?
Moan :-) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-11 05:42:26 Carlos E. R. wrote:
On 11/01/2021 07.16, J Leslie Turriff wrote:
On 2021-01-09 23:09:28 J Leslie Turriff wrote:
On 2021-01-09 06:43:41 Carlos E.R. wrote:
On 09/01/2021 13.32, J Leslie Turriff wrote:
...
So, after downloading 9313 components the process stopped with this message
(last three lines): | Retrieving package | patterns-gnome-gnome_basis_opt-20180321-lp152.7.3.x86_64
(9313/9313), 16.0 KiB ( 61 B unpacked)
| Retrieving:
patterns-gnome-gnome_basis_opt-20180321-lp152.7.3.x86_64.rpm ...................................................... [done (1.8 KiB/s)]
| Installation has completed with error.
Unlike installation of individual packages, there are no messages about installing the downloaded RPMs. What should I conclude about this?
Moan :-)
So very helpful. Does this mean that the upgrade has completed successfully, or that nothing from 15.2 has been installed? Leslie --
On 12/01/2021 03.10, J Leslie Turriff wrote:
On 2021-01-11 05:42:26 Carlos E. R. wrote:
On 11/01/2021 07.16, J Leslie Turriff wrote:
On 2021-01-09 23:09:28 J Leslie Turriff wrote:
On 2021-01-09 06:43:41 Carlos E.R. wrote:
On 09/01/2021 13.32, J Leslie Turriff wrote:
...
So, after downloading 9313 components the process stopped with this message
(last three lines): | Retrieving package | patterns-gnome-gnome_basis_opt-20180321-lp152.7.3.x86_64
(9313/9313), 16.0 KiB ( 61 B unpacked)
| Retrieving:
patterns-gnome-gnome_basis_opt-20180321-lp152.7.3.x86_64.rpm ...................................................... [done (1.8 KiB/s)]
| Installation has completed with error.
Unlike installation of individual packages, there are no messages about installing the downloaded RPMs. What should I conclude about this?
Moan :-)
So very helpful. Does this mean that the upgrade has completed successfully, or that nothing from 15.2 has been installed?
It means that I don't know what happened, looking at the information I have. Did zyyper then exit? Maybe the error means the package that had a checksum error. You can do a query to see what non 15.2 packages remain in the system: 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\.2|openSUSE_Leap_15.2|\-lp152" | less -S -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-11 22:13:37 Carlos E. R. wrote:
On 12/01/2021 03.10, J Leslie Turriff wrote:
On 2021-01-11 05:42:26 Carlos E. R. wrote:
On 11/01/2021 07.16, J Leslie Turriff wrote:
On 2021-01-09 23:09:28 J Leslie Turriff wrote:
On 2021-01-09 06:43:41 Carlos E.R. wrote:
On 09/01/2021 13.32, J Leslie Turriff wrote:
...
So, after downloading 9313 components the process stopped with this message
(last three lines): | Retrieving package | patterns-gnome-gnome_basis_opt-20180321-lp152.7.3.x86_64
(9313/9313), 16.0 KiB ( 61 B unpacked)
| Retrieving:
patterns-gnome-gnome_basis_opt-20180321-lp152.7.3.x86_64.rpm ...................................................... [done (1.8 KiB/s)]
| Installation has completed with error.
Unlike installation of individual packages, there are no messages about installing the downloaded RPMs. What should I conclude about this?
Moan :-)
So very helpful. Does this mean that the upgrade has completed successfully, or that nothing from 15.2 has been installed?
It means that I don't know what happened, looking at the information I have.
Did zyyper then exit?
Yes.
Maybe the error means the package that had a checksum error.
You can do a query to see what non 15.2 packages remain in the system:
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\.2|openSUSE_Leap_15.2|\-lp152" | less -S
Leslie --
On 2021-01-11 22:13:37 Carlos E. R. wrote:
On 12/01/2021 03.10, J Leslie Turriff wrote:
On 2021-01-11 05:42:26 Carlos E. R. wrote:
On 11/01/2021 07.16, J Leslie Turriff wrote:
On 2021-01-09 23:09:28 J Leslie Turriff wrote:
On 2021-01-09 06:43:41 Carlos E.R. wrote:
On 09/01/2021 13.32, J Leslie Turriff wrote:
...
So, after downloading 9313 components the process stopped with this message
(last three lines): | Retrieving package | patterns-gnome-gnome_basis_opt-20180321-lp152.7.3.x86_64
(9313/9313), 16.0 KiB ( 61 B unpacked)
| Retrieving:
patterns-gnome-gnome_basis_opt-20180321-lp152.7.3.x86_64.rpm ...................................................... [done (1.8 KiB/s)]
| Installation has completed with error.
Unlike installation of individual packages, there are no messages about installing the downloaded RPMs. What should I conclude about this?
Moan :-)
So very helpful. Does this mean that the upgrade has completed successfully, or that nothing from 15.2 has been installed?
It means that I don't know what happened, looking at the information I have.
Did zyyper then exit?
Maybe the error means the package that had a checksum error.
You can do a query to see what non 15.2 packages remain in the system:
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\.2|openSUSE_Leap_15.2|\-lp152" | less -S
Paging through the output from the above command, I see only "lp151" or "oss151" in the rpm filenames. grep lp151 rpmlist and grep oss151 rpmlist produces no matches. I suppose that the upgrade was aborted at the end of the download, presumably without damaging the 15.1 system. Leslie --
On 12/01/2021 06.53, J Leslie Turriff wrote:
On 2021-01-11 22:13:37 Carlos E. R. wrote:
On 12/01/2021 03.10, J Leslie Turriff wrote:
You can do a query to see what non 15.2 packages remain in the system:
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\.2|openSUSE_Leap_15.2|\-lp152" | less -S
Paging through the output from the above command, I see only "lp151" or "oss151" in the rpm filenames. grep lp151 rpmlist and grep oss151 rpmlist produces no matches. I suppose that the upgrade was aborted at the end of the download, presumably without damaging the 15.1 system.
You can post the result on susepaste if you'd like me to examine the list. Or, examine each hit. Some will be gpg keys, so no problem. The previous kernel will be in the list, this is intentional. For the true hits, well, fire up yast package manager, version tab, and see why you have still an oss151 package and if you can upgrade it. Maybe those packages are missing in your selection of repos, and you need to add some more repos or remove/replace those packages. I think that your upgrade did run to the end. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-12 02:51:50 Carlos E. R. wrote:
On 12/01/2021 06.53, J Leslie Turriff wrote:
On 2021-01-11 22:13:37 Carlos E. R. wrote:
On 12/01/2021 03.10, J Leslie Turriff wrote:
You can do a query to see what non 15.2 packages remain in the system:
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\.2|openSUSE_Leap_15.2|\-lp152" | less -S
Paging through the output from the above command, I see only "lp151" or "oss151" in the rpm filenames. grep lp151 rpmlist and grep oss151 rpmlist produces no matches. I suppose that the upgrade was aborted at the end of the download, presumably without damaging the 15.1 system.
You can post the result on susepaste if you'd like me to examine the list. Or, examine each hit.
Some will be gpg keys, so no problem.
The previous kernel will be in the list, this is intentional.
For the true hits, well, fire up yast package manager, version tab, and see why you have still an oss151 package and if you can upgrade it. Maybe those packages are missing in your selection of repos, and you need to add some more repos or remove/replace those packages.
I think that your upgrade did run to the end.
susepaste is not cooperating: | █ susepaste -t "Output from 'zypper --replacever=15.2 dup'" -e "1 day" rpmlist.txt | Paste failed :-( | @11:43:12,root@pinto | ~ | █ susepaste -t "Output from 'zypper dup'" -e "1 day" rpmlist.txt | Paste failed :-( | @11:44:02,root@pinto | ~ Since no components with lp152 appear in the output file, I question your suggestment that 'the upgrade did run to the end'. Leslie --
J Leslie Turriff composed on 2021-01-12 11:48 (UTC-0600):
susepaste is not cooperating: | █ susepaste -t "Output from 'zypper --replacever=15.2 dup'" -e "1 day" rpmlist.txt | Paste failed :-( | @11:43:12,root@pinto | ~ | █ susepaste -t "Output from 'zypper dup'" -e "1 day" rpmlist.txt | Paste failed :-( | @11:44:02,root@pinto | ~
Since no components with lp152 appear in the output file, I question your suggestment that 'the upgrade did run to the end'. The susepaste command routinely lies, known bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1166669 https://paste.opensuse.org/59040528 https://paste.opensuse.org/50630781 -- Evolution as taught in public schools, like religion, is based on faith, not on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
On 12/01/2021 19.27, Felix Miata wrote:
J Leslie Turriff composed on 2021-01-12 11:48 (UTC-0600):
susepaste is not cooperating: | █ susepaste -t "Output from 'zypper --replacever=15.2 dup'" -e "1 day" rpmlist.txt | Paste failed :-( | @11:43:12,root@pinto | ~ | █ susepaste -t "Output from 'zypper dup'" -e "1 day" rpmlist.txt | Paste failed :-( | @11:44:02,root@pinto | ~
Since no components with lp152 appear in the output file, I question your suggestment that 'the upgrade did run to the end'.
I misunderstood, sorry. Maybe you can try again and capture what goes on the terminal to a file, and upload that so that we can better know what is going on.
The susepaste command routinely lies, known bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1166669 https://paste.opensuse.org/59040528 https://paste.opensuse.org/50630781
-- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-12 12:57:35 Carlos E. R. wrote:
On 12/01/2021 19.27, Felix Miata wrote:
J Leslie Turriff composed on 2021-01-12 11:48 (UTC-0600):
susepaste is not cooperating: | █ susepaste -t "Output from 'zypper --replacever=15.2 dup'" -e "1 day"
rpmlist.txt
| Paste failed :-( | @11:43:12,root@pinto | ~ | █ susepaste -t "Output from 'zypper dup'" -e "1 day" rpmlist.txt | Paste failed :-( | @11:44:02,root@pinto | ~
Since no components with lp152 appear in the output file, I question your suggestment that 'the upgrade did run to the end'.
I misunderstood, sorry.
Maybe you can try again and capture what goes on the terminal to a file, and upload that so that we can better know what is going on.
The susepaste command routinely lies, known bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1166669 https://paste.opensuse.org/59040528 https://paste.opensuse.org/50630781
Yes, I should have done that the last time, but I didn't expect all of this drama. :-) I'll run the upgrade again and report back tomorrow (or Thursday?) when it's finished. Leslie --
J Leslie Turriff composed on 2021-01-12 13:37 (UTC-0600):
I should have done that the last time, but I didn't expect all of this drama. :-) I'll run the upgrade again and report back tomorrow (or Thursday?) when it's finished.
A command named "script" will capture an entire terminal session to a file once it's started. Ctrl-C will stop it. I've done multiple Leap online upgrades in under an hour, anywhere between 900 and maybe 1600 or 1800 packages total. My biggest installations are under 2000. This 24/7 15.1/KDE3 is 1881. The occasional use/test TW/Plasma5 I also have up ATM is 1460. -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
On 2021-01-12 16:16:34 Felix Miata wrote:
J Leslie Turriff composed on 2021-01-12 13:37 (UTC-0600):
I should have done that the last time, but I didn't expect all of this drama. :-) I'll run the upgrade again and report back tomorrow (or Thursday?) when it's finished.
A command named "script" will capture an entire terminal session to a file once it's started. Ctrl-C will stop it.
I've done multiple Leap online upgrades in under an hour, anywhere between 900 and maybe 1600 or 1800 packages total. My biggest installations are under 2000. This 24/7 15.1/KDE3 is 1881. The occasional use/test TW/Plasma5 I also have up ATM is 1460.
The download took me something like twelve hours. (I live far from the city where broadband is available.) This second run took only two hours because most of the files had been retained in cache. The upgrade appears to have completed successfully, as far as I can tell. I will reboot and see what happens. Leslie --
On 12/01/2021 23.55, J Leslie Turriff wrote:
On 2021-01-12 16:16:34 Felix Miata wrote:
J Leslie Turriff composed on 2021-01-12 13:37 (UTC-0600):
I should have done that the last time, but I didn't expect all of this drama. :-) I'll run the upgrade again and report back tomorrow (or Thursday?) when it's finished.
A command named "script" will capture an entire terminal session to a file once it's started. Ctrl-C will stop it.
I've done multiple Leap online upgrades in under an hour, anywhere between 900 and maybe 1600 or 1800 packages total. My biggest installations are under 2000. This 24/7 15.1/KDE3 is 1881. The occasional use/test TW/Plasma5 I also have up ATM is 1460.
The download took me something like twelve hours. (I live far from the city where broadband is available.) This second run took only two hours because most of the files had been retained in cache.
I think that the option "download in advance" is implied.
The upgrade appears to have completed successfully, as far as I can tell. I will reboot and see what happens.
Good! -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-12 17:18:29 Carlos E. R. wrote:
On 12/01/2021 23.55, J Leslie Turriff wrote:
On 2021-01-12 16:16:34 Felix Miata wrote:
J Leslie Turriff composed on 2021-01-12 13:37 (UTC-0600):
I should have done that the last time, but I didn't expect all of this drama. :-) I'll run the upgrade again and report back tomorrow (or Thursday?) when it's finished.
A command named "script" will capture an entire terminal session to a file once it's started. Ctrl-C will stop it.
I've done multiple Leap online upgrades in under an hour, anywhere between 900 and maybe 1600 or 1800 packages total. My biggest installations are under 2000. This 24/7 15.1/KDE3 is 1881. The occasional use/test TW/Plasma5 I also have up ATM is 1460.
The download took me something like twelve hours. (I live far from the city where broadband is available.) This second run took only two hours because most of the files had been retained in cache.
I think that the option "download in advance" is implied.
Ha! Yes, apparently this is so. It does not say that dup will terminate between downloading and installing, though. Interestingly, zypper help dup has this to say about it: | --download <MODE> Set the download-install mode. Available modes: | only, in-advance, in-heaps, as-needed | Default: DownloadDefault | -d, --download-only Only download the packages, do not install. Default: DownloadDefault is especially helpful. :-) (info zypper tells the real story.)
The upgrade appears to have completed successfully, as far as I can tell. I will reboot and see what happens.
Good!
Leslie --
On 13/01/2021 08.37, J Leslie Turriff wrote:
On 2021-01-12 17:18:29 Carlos E. R. wrote:
On 12/01/2021 23.55, J Leslie Turriff wrote:
I think that the option "download in advance" is implied.
Ha! Yes, apparently this is so. It does not say that dup will terminate between downloading and installing, though. Interestingly, zypper help dup has this to say about it:
| --download <MODE> Set the download-install mode. Available modes: | only, in-advance, in-heaps, as-needed | Default: DownloadDefault | -d, --download-only Only download the packages, do not install.
Default: DownloadDefault is especially helpful. :-) (info zypper tells the real story.)
I was going to ask if that was a typo... Here "info zypper" and search for "DownloadDefault" finds nothing. :-? If I try help, I get: --download <MODE> Set the download-install mode. Available modes: only, in-advance, in-heaps, as-needed Default: DownloadInHeaps Maybe it means it reads the default from the config file. /etc/zypp/zypp.conf commit.downloadMode = DownloadInHeaps -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-13 05:21:32 Carlos E. R. wrote:
On 13/01/2021 08.37, J Leslie Turriff wrote:
On 2021-01-12 17:18:29 Carlos E. R. wrote:
On 12/01/2021 23.55, J Leslie Turriff wrote:
I think that the option "download in advance" is implied.
Ha! Yes, apparently this is so. It does not say that dup will terminate between downloading and installing, though.
Interestingly, zypper help dup has this to say about it: | --download <MODE> Set the download-install mode. Available | modes: only, in-advance, in-heaps, as-needed | Default: DownloadDefault | -d, --download-only Only download the packages, do not install.
Default: DownloadDefault is especially helpful. :-) (info zypper tells the real story.)
I was going to ask if that was a typo...
Here "info zypper" and search for "DownloadDefault" finds nothing. :-?
If I try help, I get:
--download <MODE> Set the download-install mode. Available modes: only, in-advance, in-heaps, as-needed Default: DownloadInHeaps
Maybe it means it reads the default from the config file.
/etc/zypp/zypp.conf
commit.downloadMode = DownloadInHeap
No, not a typo. Full output from zypper help dup:
| dist-upgrade (dup) [OPTIONS]
|
| Perform a distribution upgrade.
|
| Command options:
|
| --from
On 13/01/2021 19.21, J Leslie Turriff wrote:
On 2021-01-13 05:21:32 Carlos E. R. wrote:
...
| --download <MODE> Set the download-install mode. Available modes: only, in-advance, | in-heaps, as-needed Default: DownloadDefault
The same command here responds: --download <MODE> Set the download-install mode. Available modes: only, in-advance, in-heaps, as-needed Default: DownloadInHeaps I edit the config file, and now: --download <MODE> Set the download-install mode. Available modes: only, in-advance, in-heaps, as-needed Default: DownloadInAdvance The command help reflects as default whatever you configure in its config file. Cool! -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-13 12:35:17 Carlos E. R. wrote:
On 13/01/2021 19.21, J Leslie Turriff wrote:
On 2021-01-13 05:21:32 Carlos E. R. wrote:
...
| --download <MODE> Set the download-install mode. Available | modes: only, in-advance, in-heaps, as-needed Default: DownloadDefault
The same command here responds:
--download <MODE> Set the download-install mode. Available modes: only, in-advance, in-heaps, as-needed Default: DownloadInHeaps
I edit the config file, and now:
--download <MODE> Set the download-install mode. Available modes: only, in-advance, in-heaps, as-needed Default: DownloadInAdvance
The command help reflects as default whatever you configure in its config file. Cool!
Interesting. So it appears that the default value is not actually set in the configuration file supplied with the tool, where one would expect it. Leslie --
On 13/01/2021 19.45, J Leslie Turriff wrote:
On 2021-01-13 12:35:17 Carlos E. R. wrote:
On 13/01/2021 19.21, J Leslie Turriff wrote:
On 2021-01-13 05:21:32 Carlos E. R. wrote:
...
| --download <MODE> Set the download-install mode. Available | modes: only, in-advance, in-heaps, as-needed Default: DownloadDefault
The same command here responds:
--download <MODE> Set the download-install mode. Available modes: only, in-advance, in-heaps, as-needed Default: DownloadInHeaps
I edit the config file, and now:
--download <MODE> Set the download-install mode. Available modes: only, in-advance, in-heaps, as-needed Default: DownloadInAdvance
The command help reflects as default whatever you configure in its config file. Cool!
Interesting. So it appears that the default value is not actually set in the configuration file supplied with the tool, where one would expect it.
No, the reverse! The default value is not hardcoded in the binary, as is the usual custom, but is written in the configuration file supplied with the tool. Thus the default value can be modified by the admin, _and_ the modification is reported in the man page, dynamically. It is the later which I have never seen. I wonder how they have managed that trick. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-14 05:45:10 Carlos E. R. wrote:
On 13/01/2021 19.45, J Leslie Turriff wrote:
On 2021-01-13 12:35:17 Carlos E. R. wrote:
On 13/01/2021 19.21, J Leslie Turriff wrote:
On 2021-01-13 05:21:32 Carlos E. R. wrote:
...
| --download <MODE> Set the download-install mode. Available | modes: only, in-advance, in-heaps, as-needed Default: DownloadDefault
The same command here responds:
--download <MODE> Set the download-install mode. Available modes: only, in-advance, in-heaps, as-needed Default: DownloadInHeaps
I edit the config file, and now:
--download <MODE> Set the download-install mode. Available modes: only, in-advance, in-heaps, as-needed Default: DownloadInAdvance
The command help reflects as default whatever you configure in its config file. Cool!
Interesting. So it appears that the default value is not actually set in the configuration file supplied with the tool, where one would expect it.
No, the reverse!
The default value is not hardcoded in the binary, as is the usual custom, but is written in the configuration file supplied with the tool. Thus the default value can be modified by the admin, _and_ the modification is reported in the man page, dynamically.
It is the later which I have never seen. I wonder how they have managed that trick.
But the configuration file /etc/zypp/zypp.conf contains | ## commit.downloadMode = so 1) there is no default value coded, and 2) in any case, the statement is commented out. Leslie --
On 14/01/2021 22.13, J Leslie Turriff wrote:
On 2021-01-14 05:45:10 Carlos E. R. wrote:
On 13/01/2021 19.45, J Leslie Turriff wrote:
On 2021-01-13 12:35:17 Carlos E. R. wrote:
On 13/01/2021 19.21, J Leslie Turriff wrote:
On 2021-01-13 05:21:32 Carlos E. R. wrote:
...
The command help reflects as default whatever you configure in its config file. Cool!
Interesting. So it appears that the default value is not actually set in the configuration file supplied with the tool, where one would expect it.
No, the reverse!
The default value is not hardcoded in the binary, as is the usual custom, but is written in the configuration file supplied with the tool. Thus the default value can be modified by the admin, _and_ the modification is reported in the man page, dynamically.
It is the later which I have never seen. I wonder how they have managed that trick.
But the configuration file /etc/zypp/zypp.conf contains | ## commit.downloadMode = so 1) there is no default value coded, and 2) in any case, the statement is commented out.
Ok, then there is a default hardcoded value, but if you configure one, then the manpage reports that value as default. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-13 01:37:50 J Leslie Turriff wrote:
On 2021-01-12 17:18:29 Carlos E. R. wrote:
On 12/01/2021 23.55, J Leslie Turriff wrote:
On 2021-01-12 16:16:34 Felix Miata wrote:
J Leslie Turriff composed on 2021-01-12 13:37 (UTC-0600):
I should have done that the last time, but I didn't expect all of this drama. :-) I'll run the upgrade again and report back tomorrow (or Thursday?) when it's finished.
A command named "script" will capture an entire terminal session to a file once it's started. Ctrl-C will stop it.
I've done multiple Leap online upgrades in under an hour, anywhere between 900 and maybe 1600 or 1800 packages total. My biggest installations are under 2000. This 24/7 15.1/KDE3 is 1881. The occasional use/test TW/Plasma5 I also have up ATM is 1460.
The download took me something like twelve hours. (I live far from the city where broadband is available.) This second run took only two hours because most of the files had been retained in cache.
I think that the option "download in advance" is implied.
Ha! Yes, apparently this is so. It does not say that dup will terminate between downloading and installing, though.
Interestingly, zypper help dup has this to say about it: | --download <MODE> Set the download-install mode. Available | modes: only, in-advance, in-heaps, as-needed | Default: DownloadDefault | -d, --download-only Only download the packages, do not install.
Default: DownloadDefault is especially helpful. :-) (info zypper tells the real story.)
The upgrade appears to have completed successfully, as far as I can tell. I will reboot and see what happens.
Good!
Leslie --
And the reboot was successful! The only glitch I've found so far (has nothing to do with the upgrade process) is that the output from the update-alternates command has changed slightly, breaking a bash script. Leslie --
On 12/01/2021 23.16, Felix Miata wrote:
J Leslie Turriff composed on 2021-01-12 13:37 (UTC-0600):
I should have done that the last time, but I didn't expect all of this drama. :-) I'll run the upgrade again and report back tomorrow (or Thursday?) when it's finished.
A command named "script" will capture an entire terminal session to a file once it's started. Ctrl-C will stop it.
I had forgotten about that one. How would you use it? -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Carlos E. R. composed on 2021-01-12 23:57 (UTC+0100):
Felix Miata wrote:
A command named "script" will capture an entire terminal session to a file once it's started. Ctrl-C will stop it.
I had forgotten about that one. How would you use it?
I use it on the ttys for activity I do not want to, or cannot do, in Konsole or Xterm. -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
On 13/01/2021 03.10, Felix Miata wrote:
Carlos E. R. composed on 2021-01-12 23:57 (UTC+0100):
Felix Miata wrote:
A command named "script" will capture an entire terminal session to a file once it's started. Ctrl-C will stop it.
I had forgotten about that one. How would you use it?
I use it on the ttys for activity I do not want to, or cannot do, in Konsole or Xterm.
I mean what exactly do you type. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
* Carlos E. R.
On 13/01/2021 03.10, Felix Miata wrote:
Carlos E. R. composed on 2021-01-12 23:57 (UTC+0100):
Felix Miata wrote:
A command named "script" will capture an entire terminal session to a file once it's started. Ctrl-C will stop it.
I had forgotten about that one. How would you use it?
I use it on the ttys for activity I do not want to, or cannot do, in Konsole or Xterm.
I mean what exactly do you type.
one might start with the basics: script --help and, last resort: man script pinfo script just saying -- (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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2021-01-13 at 09:21 -0500, Patrick Shanahan wrote:
* Carlos E. R. <> [01-13-21 06:16]:
On 13/01/2021 03.10, Felix Miata wrote:
Carlos E. R. composed on 2021-01-12 23:57 (UTC+0100):
Felix Miata wrote:
A command named "script" will capture an entire terminal session to a file once it's started. Ctrl-C will stop it.
I had forgotten about that one. How would you use it?
I use it on the ttys for activity I do not want to, or cannot do, in Konsole or Xterm.
I mean what exactly do you type.
one might start with the basics: script --help
and, last resort: man script pinfo script
I did that. I got nowhere. - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYAAvsRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV43YAn3cylT9JFC8fWtZ0gxKg 5XGYzyvTAJ4oT++MGqbeHsltS/B4M08DxgYljw== =ljsz -----END PGP SIGNATURE-----
Carlos E. R. composed on 2021-01-13 12:13 (UTC+0100):
Felix Miata wrote:
I use it on the ttys for activity I do not want to, or cannot do, in Konsole or Xterm.
I mean what exactly do you type.
I was expecting 'A command named "script"' in my 2021-01-12 17:16 -0500 thread reply would have been enough for readers to understand that script is a binary utility, not some shell script. "Exactly" depends on what you are trying to record. Here's a template: # script # command 1 # command 2 # command 3 # ... # command n # Ctrl-C # susepaste -n carlos typescript # man script -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
On 2021-01-13 12:38:45 Felix Miata wrote:
Carlos E. R. composed on 2021-01-13 12:13 (UTC+0100):
Felix Miata wrote:
I use it on the ttys for activity I do not want to, or cannot do, in Konsole or Xterm.
I mean what exactly do you type.
I was expecting 'A command named "script"' in my 2021-01-12 17:16 -0500 thread reply would have been enough for readers to understand that script is a binary utility, not some shell script.
"Exactly" depends on what you are trying to record. Here's a template:
# script # command 1 # command 2 # command 3 # ... # command n # Ctrl-C # susepaste -n carlos typescript
# man script
I'm always fascinated by the bizarre mental gymnastics that programmers go through when naming their programs. :-) I would expect a program designed for recording terminal dialog to be called 'record'. Leslie --
On 13/01/2021 19.48, J Leslie Turriff wrote:
On 2021-01-13 12:38:45 Felix Miata wrote:
Carlos E. R. composed on 2021-01-13 12:13 (UTC+0100):
Felix Miata wrote:
I use it on the ttys for activity I do not want to, or cannot do, in Konsole or Xterm.
I mean what exactly do you type.
I was expecting 'A command named "script"' in my 2021-01-12 17:16 -0500 thread reply would have been enough for readers to understand that script is a binary utility, not some shell script.
I knew perfectly that it is a command named script. I looked at the man page. Told me nothing.
"Exactly" depends on what you are trying to record. Here's a template:
# script # command 1 # command 2 # command 3 # ... # command n # Ctrl-C # susepaste -n carlos typescript
AHH! Now I understand. This is what I wanted. Thanks :-)
# man script
Has no examples, only a list of options. Useless.
I'm always fascinated by the bizarre mental gymnastics that programmers go through when naming their programs. :-) I would expect a program designed for recording terminal dialog to be called 'record'.
Absolutely! Or capture. Try "apropos capture" or "apropos record". -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-14 12:41, Carlos E. R. wrote:
On 13/01/2021 19.48, J Leslie Turriff wrote:
I'm always fascinated by the bizarre mental gymnastics that programmers go through when naming their programs.:-) I would expect a program designed for recording terminal dialog to be called 'record'. Absolutely!
Well, there's all kinds of naming schemes and just this particular one I think we have to excuse. Script is from 3BSD released 1979. "Script" produced a typescript (typewritten and not by hand as manuscript), or script for short. 3BSD from that year man ./usr/man/man1/script.1 | tail -1 3rd Berkeley Distribution 8/1/79 SCRIPT(1) -- /bengan
On 2021-01-12 16:57:21 Carlos E. R. wrote:
On 12/01/2021 23.16, Felix Miata wrote:
J Leslie Turriff composed on 2021-01-12 13:37 (UTC-0600):
I should have done that the last time, but I didn't expect all of this drama. :-) I'll run the upgrade again and report back tomorrow (or Thursday?) when it's finished.
A command named "script" will capture an entire terminal session to a file once it's started. Ctrl-C will stop it.
I had forgotten about that one. How would you use it?
Dunno about that; I used zypper --releasever=15.2 dup |& tee zypperDup.log Leslie --
On 13/01/2021 08.38, J Leslie Turriff wrote:
On 2021-01-12 16:57:21 Carlos E. R. wrote:
On 12/01/2021 23.16, Felix Miata wrote:
J Leslie Turriff composed on 2021-01-12 13:37 (UTC-0600):
I should have done that the last time, but I didn't expect all of this drama. :-) I'll run the upgrade again and report back tomorrow (or Thursday?) when it's finished.
A command named "script" will capture an entire terminal session to a file once it's started. Ctrl-C will stop it.
I had forgotten about that one. How would you use it?
Dunno about that; I used zypper --releasever=15.2 dup |& tee zypperDup.log
Yes, that's more or less what I use, but sometimes with some programs I have problems with the prompts. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-12 02:51:50 Carlos E. R. wrote:
On 12/01/2021 06.53, J Leslie Turriff wrote:
On 2021-01-11 22:13:37 Carlos E. R. wrote:
On 12/01/2021 03.10, J Leslie Turriff wrote:
You can do a query to see what non 15.2 packages remain in the system:
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\.2|openSUSE_Leap_15.2|\-lp152" | less -S
Paging through the output from the above command, I see only "lp151" or "oss151" in the rpm filenames. grep lp151 rpmlist and grep oss151 rpmlist produces no matches. I suppose that the upgrade was aborted at the end of the download, presumably without damaging the 15.1 system.
You can post the result on susepaste if you'd like me to examine the list. Or, examine each hit.
Some will be gpg keys, so no problem.
The previous kernel will be in the list, this is intentional.
For the true hits, well, fire up yast package manager, version tab, and see why you have still an oss151 package and if you can upgrade it. Maybe those packages are missing in your selection of repos, and you need to add some more repos or remove/replace those packages.
I think that your upgrade did run to the end.
Either of these links will show the contents of the rpmlist output file: | https://paste.opensuse.org/59040528 | https://paste.opensuse.org/50630781 Leslie --
On 2021-01-09 06:43:41 Carlos E.R. wrote:
On 09/01/2021 13.32, J Leslie Turriff wrote:
I'm following the instructions in SDB:System upgrade, using the zypper method. I've performed the preliminary "Make sure you are up to date" steps successfully, but I'm having problems with the actual update step. Even though I have removed the Packman, Wine and Font repositories from my repository configuration, I'm getting errors relating to components that were installed from those repositories:
Certainly. Every repo that you remove will cause problems with packages that were installed from those repos. Thus, for instance, I would never remove packman. Bad idea.
Remove only the repositories that you actually want their packages to be switched to the mainline version.
█ zypper --releasever=15.2 lr -u
Don't use "--releasever" with this command, might restrict the information.
[snip]
Do you really need the debug repos on?
Should I not? Perhaps I misunderstand the purpose of the *-debug components? They're for collecting debugging info for bug reports, yes?
[snip]
Do you really need the source repos on?
For building packages from tarballs.
@06:16:24,root@pinto ~ █ zypper --releasever=15.2 dup Warning: Enforced setting: $releasever=15.2
...
Problem: problem with installed package int10h-oldschoolpc-fonts-1.0-lp151.6.1.noarch Solution 1: install int10h-oldschoolpc-fonts-2.2-lp152.4.3.1.noarch (with vendor change) obs://build.opensuse.org/M17N --> openSUSE Solution 2: keep obsolete int10h-oldschoolpc-fonts-1.0-lp151.6.1.noarch
Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] (c): c
How can I bypass these problem packages?
You can't bypass. If your decision was to remove the Font repo, then your next decision has to be #1 above.
Leslie --
On 13/01/2021 20.46, J Leslie Turriff wrote:
On 2021-01-09 06:43:41 Carlos E.R. wrote:
On 09/01/2021 13.32, J Leslie Turriff wrote:
I'm following the instructions in SDB:System upgrade, using the zypper method. I've performed the preliminary "Make sure you are up to date" steps successfully, but I'm having problems with the actual update step. Even though I have removed the Packman, Wine and Font repositories from my repository configuration, I'm getting errors relating to components that were installed from those repositories:
Certainly. Every repo that you remove will cause problems with packages that were installed from those repos. Thus, for instance, I would never remove packman. Bad idea.
Remove only the repositories that you actually want their packages to be switched to the mainline version.
█ zypper --releasever=15.2 lr -u
Don't use "--releasever" with this command, might restrict the information.
[snip]
Do you really need the debug repos on?
Should I not? Perhaps I misunderstand the purpose of the *-debug components? They're for collecting debugging info for bug reports, yes?
Yes, exactly. On dumps, traceback tools, etc.
[snip]
Do you really need the source repos on?
For building packages from tarballs.
Ah, ok so you do that, thus you need them. :-) It is not "typical". -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-14 05:47:15 Carlos E. R. wrote:
On 13/01/2021 20.46, J Leslie Turriff wrote:
On 2021-01-09 06:43:41 Carlos E.R. wrote:
On 09/01/2021 13.32, J Leslie Turriff wrote:
I'm following the instructions in SDB:System upgrade, using the zypper method. I've performed the preliminary "Make sure you are up to date" steps successfully, but I'm having problems with the actual update step. Even though I have removed the Packman, Wine and Font repositories from my repository configuration, I'm getting errors relating to components that were installed from those repositories:
Certainly. Every repo that you remove will cause problems with packages that were installed from those repos. Thus, for instance, I would never remove packman. Bad idea.
Remove only the repositories that you actually want their packages to be switched to the mainline version.
█ zypper --releasever=15.2 lr -u
Don't use "--releasever" with this command, might restrict the information.
[snip]
Do you really need the debug repos on?
Should I not? Perhaps I misunderstand the purpose of the *-debug components? They're for collecting debugging info for bug reports, yes?
Yes, exactly. On dumps, traceback tools, etc.
[snip]
Do you really need the source repos on?
For building packages from tarballs.
Ah, ok so you do that, thus you need them. :-)
It is not "typical".
I find that there are many packages in the OpenSuSE repositories that are unusably old, so I must compile from source to get current versions. Leslie --
On 14/01/2021 22.16, J Leslie Turriff wrote:
On 2021-01-14 05:47:15 Carlos E. R. wrote:
On 13/01/2021 20.46, J Leslie Turriff wrote:
[snip]
Do you really need the source repos on?
For building packages from tarballs.
Ah, ok so you do that, thus you need them. :-)
It is not "typical".
I find that there are many packages in the OpenSuSE repositories that are unusably old, so I must compile from source to get current versions.
Sure, of course. I did that in the past as well, but I did not use source repos. Don't you find a newer version in the extra repositories? -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-14 15:25:58 Carlos E.R. wrote:
On 14/01/2021 22.16, J Leslie Turriff wrote:
On 2021-01-14 05:47:15 Carlos E. R. wrote:
On 13/01/2021 20.46, J Leslie Turriff wrote:
[snip]
Do you really need the source repos on?
For building packages from tarballs.
Ah, ok so you do that, thus you need them. :-)
It is not "typical".
I find that there are many packages in the OpenSuSE repositories that are unusably old, so I must compile from source to get current versions.
Sure, of course. I did that in the past as well, but I did not use source repos.
Don't you find a newer version in the extra repositories?
Which 'extra' repositories? Other than Packman, the only extras I have are Fonts and Wine. Even if I use the OpenSuSE Download webpage, most stuff is back-leveled. Leslie --
On 15/01/2021 05.06, J Leslie Turriff wrote:
On 2021-01-14 15:25:58 Carlos E.R. wrote:
On 14/01/2021 22.16, J Leslie Turriff wrote:
On 2021-01-14 05:47:15 Carlos E. R. wrote:
On 13/01/2021 20.46, J Leslie Turriff wrote:
[snip]
Do you really need the source repos on?
For building packages from tarballs.
Ah, ok so you do that, thus you need them. :-)
It is not "typical".
I find that there are many packages in the OpenSuSE repositories that are unusably old, so I must compile from source to get current versions.
Sure, of course. I did that in the past as well, but I did not use source repos.
Don't you find a newer version in the extra repositories?
Which 'extra' repositories? Other than Packman, the only extras I have are Fonts and Wine. Even if I use the OpenSuSE Download webpage, most stuff is back-leveled.
There are hundreds of extra repositories. Suppose for example that I want a recent version of kwrite. The version available in oss is "20.04.2", but from some extra repository I can get 20.12.1 In Firefox, I click on my "home" page with happens to be https://search.opensuse.org/ There I click on "packages". https://search.opensuse.org/packages/ I type kwrite: I get: https://software.opensuse.org/search?q=kwrite&baseproject=openSUSE%3AFactory With two entries, one kwrite, another kwrited5. I click on the first: https://software.opensuse.org/package/kwrite I click "Show kwrite for other distributions", then look at the paragraph for 15.2, and click on "show experimental packages", and get two posibilities: KDE:Applications Experimental 20.12.1 KDE:Unstable:Applications Experimental 21.03.70git.20210113T... I would then capture the string of the repo URL and add it to my system. Click on "Expert download", then on "add repository and add manually". zypper addrepo https://download.opensuse.org/repositories/KDE:Unstable:Applications/KDE_Uns... zypper refresh zypper install kwrite I would be wary of adding that particular repo, though. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 1/14/21 11:06 PM, J Leslie Turriff wrote:
On 2021-01-14 15:25:58 Carlos E.R. wrote:
On 14/01/2021 22.16, J Leslie Turriff wrote:
snip
Which 'extra' repositories? Other than Packman, the only extras I have are Fonts and Wine. Even if I use the OpenSuSE Download webpage, most stuff is back-leveled.
Leslie --
Besides using the OBS as Carlos showed (which IME often has the most recent versions), there are other repo's for desktop managers such as KDE and Gnome. With KDE, be extra cautious about any apps that require a change to the underlying KDE or Qt frameworks, as changes there can have a lot of implications. https://en.opensuse.org/SDB:KDE_repositories https://en.opensuse.org/GNOME_repositories I have used all of these many times over the years. I've found them to be reliable and safe as long as you know what you are doing. --dg Leap 15.1/25.2, KDE Plasma
On 09/01/2021 13.51, Olaf Hering wrote:
Am Sat, 9 Jan 2021 06:32:49 -0600 schrieb J Leslie Turriff
: How can I bypass these problem packages?
zypper dup --allow-vendor-change
Warning: this can have unexpected results. It will certainly remove the questions, but will switch the decision making to zypper and away from the administrator. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Sat, 9 Jan 2021 14:46:35 +0100
Olaf Hering
Am Sat, 9 Jan 2021 14:22:20 +0100 schrieb "Carlos E. R."
: Warning: this can have unexpected results
This is wrong.
That depends on what the user is expecting :)
'dup' aligns the packages based on repo priorities. With the provided 'zypper lr' output the result will be as expected.
If they've read the manual and know to expect that. I think that's what Carlos is warning about.
Olaf
On 09/01/2021 17.35, Dave Howorth wrote:
On Sat, 9 Jan 2021 14:46:35 +0100 Olaf Hering
wrote: Am Sat, 9 Jan 2021 14:22:20 +0100 schrieb "Carlos E. R."
: Warning: this can have unexpected results
This is wrong.
That depends on what the user is expecting :)
'dup' aligns the packages based on repo priorities. With the provided 'zypper lr' output the result will be as expected.
If they've read the manual and know to expect that. I think that's what Carlos is warning about.
Basically :-) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
participants (10)
-
Bengt Gördén
-
Carlos E. R.
-
Carlos E. R.
-
Carlos E.R.
-
Dave Howorth
-
DennisG
-
Felix Miata
-
J Leslie Turriff
-
Olaf Hering
-
Patrick Shanahan