I noticed two odd things during today’s update, highlighted in red:
>sudo zypper dup
...
The following 3 NEW packages are going to be installed:
glibc-32bit liblsmash2 libx264-161
The following 39 packages are going to be upgraded:
ffmpeg-4 gstreamer-plugins-ugly gstreamer-plugins-ugly-orig-addon libavcodec57 libavcodec58_91
libavdevice57 libavdevice58_10 libavfilter6 libavfilter7_85 libavformat57 libavformat58_45
libavresample3 libavresample4_0 libavutil55 libavutil56_51 libde265-0 libfaad2 libgpac10 libheif1
libpostproc54 libpostproc55_7 libquicktime0 libswresample2 libswresample3_7 libswscale4 libswscale5_7
libtirpc3 libtirpc-netconfig libvlc5 libvlccore9 openSUSE-release openSUSE-release-appliance-custom
vlc vlc-codec-gstreamer vlc-codecs vlc-noX vlc-qt vlc-vdpau x264
The following product is going to be upgraded:
openSUSE Tumbleweed 20201224-0 -> 20201227-0
The following package is going to change architecture:
libx264-160 x86_64 -> i586
39 packages to upgrade, 3 new, 1 to change arch.
Overall download size: 30.9 MiB. Already cached: 0 B. After the operation, additional 6.9 MiB will be
used.
Continue? [y/n/v/...? shows all options] (y): y
After the update, I cleaned up with the following command and all appears normal.
> sudo zypper remove libx264-160 glibc-32bit
Reading installed packages...
Resolving package dependencies...
The following 2 packages are going to be REMOVED:
glibc-32bit libx264-160
2 packages to remove.
After the operation, 6.0 MiB will be freed.
Continue? [y/n/v/...? shows all options] (y): y
(1/2) Removing libx264-160-0.160+git20200702.cde9a933-1.9.i586 ...................................[done]
(2/2) Removing glibc-32bit-2.32-4.1.x86_64 .......................................................[done]
Any ideas on why the architecture change occurred? Apparently, that’s what pulled in glibc-32bit.
Hi
When you updated the x86_64 build was being updated/built, likely the x86_64 version had not propagated to the mirrors… it’s now libx264-161 in Packman…
Look at the 3 NEW packages being installed in my OP. One of them was libx264-161, on the same transaction where libx264-160 was getting an architecture change. So I’m still curious.
Hi
Again, could very will be the state of the repos at the time you were updating, different mirrors can have different packages, likely all a timing issue when the update was run.
If you add verbosity to the dup (I always use zypper -vvv [or -vvvv] dup) it can provide further information on what is actually happening including what mirrors packages are arriving from.
“zypper dup” wanted to change “libx264-160” to i586 architecture.
I cancelled out of that, and instead tried “zypper up”. That warned me that I should use “zypper dup”, but otherwise allowed me to do it.
It looks as if this made the same changes as “zypper dup” except that it did not do the architecture change.
After that, I tried “zypper dup” again, and the only change it wanted was the architecture change for the one package. I cancelled out, and I think I’ll leave things as they are until next update.
Note that I already have glibc-32bit installed for other reasons, so I didn’t see that part.
I had the same change of architecture issue when I ran sudo zypper -vvv dup yesterday evening. Thought about it, and decided that Packman probably hadn’t uploaded the x64 version yet, so I cancelled, and decided to try again in the morning.
No notification of an architecture change this morning, so I have run the update.
The two main things I have learned for using zypper dup are to always use verbosity and check what package changes are proposed, and, if in doubt, leave updating until the next day to see if the apparent package oddness has disappeared.
Checking this morning, “libx264-160” no longer exists in Packman. So you won’t see that architecture change. Your existing “libx264-160” might show up as an orphaned package, in which case you can just remove it.
