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/

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 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 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 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 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 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 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 Sun, 10 Jan 2021 21:49:32 -0600 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

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 --

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 --

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 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 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 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 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 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)

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 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 --

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 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 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 Restrict upgrade to specified repository. | --details Show the detailed installation summary. Default: false | --replacefiles Install the packages even if they replace files from other, already | installed, packages. Default is to treat file conflicts as an error. | --download-as-needed disables the fileconflict check. Default: false | -r, --repo Work only with the specified repository. | -l, --auto-agree-with-licenses | Automatically say 'yes' to third party license confirmation prompt. See | 'man zypper' for more details. Default: false | -D, --dry-run Don't change anything, just report what would be done. A meaningful file | conflict check can only be performed if used together with | '--download-only'. Default: false | -y, --no-confirm Don't require user interaction. Alias for the --non-interactive global | option. Default: false | --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. | | Solver options | | --debug-solver Create a solver test case for debugging. | --force-resolution Force the solver to find a solution (even an aggressive one) rather than | asking. | -R, --no-force-resolution Do not force the solver to find a solution, let it ask. | --solver-focus <MODE> Set the solvers general attitude when resolving a job. | --recommends Install also recommended packages in addition to the required ones. | --no-recommends Do not install recommended packages, only required ones. | | Expert options | | --allow-downgrade | --no-allow-downgrade Whether to allow downgrading installed resolvables. | --allow-name-change | --no-allow-name-change Whether to allow changing the names of installed resolvables. | --allow-arch-change | --no-allow-arch-change Whether to allow changing the architecture of installed resolvables. | --allow-vendor-change | --no-allow-vendor-change | Whether to allow changing the vendor of installed resolvables. Leslie --

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 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 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 --

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/

* 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 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

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 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-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 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 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 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 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)

Am Sat, 9 Jan 2021 14:22:20 +0100 schrieb "Carlos E. R." :

Warning: this can have unexpected results

This is wrong. 'dup' aligns the packages based on repo priorities. With the provided 'zypper lr' output the result will be as expected. 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)