Packages change without EVR change?
The following 41 packages are going to be reinstalled: adwaita-qt5 boost-license1_81_0 gio-branding-openSUSE glibc glibc-extra glibc-locale glibc-locale-base gnome-menus-branding-openSUSE gtk2-branding-openSUSE gtk3-branding-openSUSE gtk4-branding-openSUSE libadwaitaqt5-1 libappindicator3-1 libboost_date_time1_81_0 libboost_date_time1_81_0-x86-64-v3 libboost_filesystem1_81_0 libboost_filesystem1_81_0-x86-64-v3 libboost_iostreams1_81_0 libboost_iostreams1_81_0-x86-64-v3 libboost_locale1_81_0 libboost_locale1_81_0-x86-64-v3 libboost_thread1_81_0 libboost_thread1_81_0-x86-64-v3 libdbusmenu-glib4 libdbusmenu-gtk3-4 libfftw3-3 libjavascriptcoregtk-4_1-0 libmetis5 libopenblas_pthreads0 libpoppler127 libpoppler-cpp0 libpoppler-glib8 libwebkit2gtk-4_1-0 NetworkManager-branding-openSUSE nscd poppler-tools QGnomePlatform-qt5 qtdeclarative-imports-provides-qt5 typelib-1_0-JavaScriptCore-4_1 typelib-1_0-WebKit2-4_1 webkit2gtk-4_1-injected-bundles Looking at the first package installed package solvable:name: adwaita-qt5 solvable:arch: x86_64 solvable:evr: 1.4.2-3.2 solvable:vendor: openSUSE solvable:provides: adwaita-qt5 = 1.4.2-3.2 adwaita-qt5(x86-64) = 1.4.2-3.2 ... solvable:buildtime: 1679293687 solvable:buildhost: beatles Package from repository solvable:name: adwaita-qt5 solvable:arch: x86_64 solvable:evr: 1.4.2-3.2 solvable:vendor: openSUSE solvable:provides: adwaita-qt5 = 1.4.2-3.2 ... solvable:buildtime: 1681803752 solvable:buildhost: lamb02 Packages also have different Requires etc. So nothing visible to user changed, but package was mysteriously replaced by different build. How is it possible?
Hi Andrei,
Andrei Borzenkov
The following 41 packages are going to be reinstalled: adwaita-qt5 boost-license1_81_0 gio-branding-openSUSE glibc glibc-extra glibc-locale glibc-locale-base gnome-menus-branding-openSUSE gtk2-branding-openSUSE gtk3-branding-openSUSE gtk4-branding-openSUSE libadwaitaqt5-1 libappindicator3-1 libboost_date_time1_81_0 libboost_date_time1_81_0-x86-64-v3 libboost_filesystem1_81_0 libboost_filesystem1_81_0-x86-64-v3 libboost_iostreams1_81_0 libboost_iostreams1_81_0-x86-64-v3 libboost_locale1_81_0 libboost_locale1_81_0-x86-64-v3 libboost_thread1_81_0 libboost_thread1_81_0-x86-64-v3 libdbusmenu-glib4 libdbusmenu-gtk3-4 libfftw3-3 libjavascriptcoregtk-4_1-0 libmetis5 libopenblas_pthreads0 libpoppler127 libpoppler-cpp0 libpoppler-glib8 libwebkit2gtk-4_1-0 NetworkManager-branding-openSUSE nscd poppler-tools QGnomePlatform-qt5 qtdeclarative-imports-provides-qt5 typelib-1_0-JavaScriptCore-4_1 typelib-1_0-WebKit2-4_1 webkit2gtk-4_1-injected-bundles
Looking at the first package
installed package
solvable:name: adwaita-qt5 solvable:arch: x86_64 solvable:evr: 1.4.2-3.2 solvable:vendor: openSUSE solvable:provides: adwaita-qt5 = 1.4.2-3.2 adwaita-qt5(x86-64) = 1.4.2-3.2 ... solvable:buildtime: 1679293687 solvable:buildhost: beatles
Package from repository
solvable:name: adwaita-qt5 solvable:arch: x86_64 solvable:evr: 1.4.2-3.2 solvable:vendor: openSUSE solvable:provides: adwaita-qt5 = 1.4.2-3.2 ... solvable:buildtime: 1681803752 solvable:buildhost: lamb02
Packages also have different Requires etc. So nothing visible to user changed, but package was mysteriously replaced by different build. How is it possible?
I assume you ran a `zypper dup` right? Afaik a zypper dup is more akin
to `dnf distro-sync`, i.e. fetch the latest (time wise) build from the
repositories and install that one, irrespective of the EVR. That's why
you are seeing a reinstall of packages without an EVR change, albeit I
am wondering why there was no rebuild counter bump.
Cheers,
Dan
--
Dan Čermák
On Fri, Apr 21, 2023 at 8:52 AM Dan Čermák
Hi Andrei,
Andrei Borzenkov
writes: The following 41 packages are going to be reinstalled: adwaita-qt5 boost-license1_81_0 gio-branding-openSUSE glibc glibc-extra glibc-locale glibc-locale-base gnome-menus-branding-openSUSE gtk2-branding-openSUSE gtk3-branding-openSUSE gtk4-branding-openSUSE libadwaitaqt5-1 libappindicator3-1 libboost_date_time1_81_0 libboost_date_time1_81_0-x86-64-v3 libboost_filesystem1_81_0 libboost_filesystem1_81_0-x86-64-v3 libboost_iostreams1_81_0 libboost_iostreams1_81_0-x86-64-v3 libboost_locale1_81_0 libboost_locale1_81_0-x86-64-v3 libboost_thread1_81_0 libboost_thread1_81_0-x86-64-v3 libdbusmenu-glib4 libdbusmenu-gtk3-4 libfftw3-3 libjavascriptcoregtk-4_1-0 libmetis5 libopenblas_pthreads0 libpoppler127 libpoppler-cpp0 libpoppler-glib8 libwebkit2gtk-4_1-0 NetworkManager-branding-openSUSE nscd poppler-tools QGnomePlatform-qt5 qtdeclarative-imports-provides-qt5 typelib-1_0-JavaScriptCore-4_1 typelib-1_0-WebKit2-4_1 webkit2gtk-4_1-injected-bundles
Looking at the first package
installed package
solvable:name: adwaita-qt5 solvable:arch: x86_64 solvable:evr: 1.4.2-3.2 solvable:vendor: openSUSE solvable:provides: adwaita-qt5 = 1.4.2-3.2 adwaita-qt5(x86-64) = 1.4.2-3.2 ... solvable:buildtime: 1679293687 solvable:buildhost: beatles
Package from repository
solvable:name: adwaita-qt5 solvable:arch: x86_64 solvable:evr: 1.4.2-3.2 solvable:vendor: openSUSE solvable:provides: adwaita-qt5 = 1.4.2-3.2 ... solvable:buildtime: 1681803752 solvable:buildhost: lamb02
Packages also have different Requires etc. So nothing visible to user changed, but package was mysteriously replaced by different build. How is it possible?
I assume you ran a `zypper dup` right? Afaik a zypper dup is more akin to `dnf distro-sync`, i.e. fetch the latest (time wise) build from the repositories and install that one, irrespective of the EVR. That's why you are seeing a reinstall of packages without an EVR change,
You seriously think I am not aware of it? :)
albeit I am wondering why there was no rebuild counter bump.
Yes, that was exactly the question.
On Friday 2023-04-21 07:52, Dan Čermák via openSUSE Factory wrote:
The following 41 packages are going to be reinstalled: adwaita-qt5 boost-license1_81_0 gio-branding-openSUSE glibc glibc-extra
Packages also have different Requires etc. So nothing visible to user changed, but package was mysteriously replaced by different build. How is it possible?
I can think of: 1. If the package is deleted (osc rdelete) then recreated, %release = CI_CNT.B_CNT is reset to 1.1. [in practice this limits it to devel projects, because we don't normally delete packages from Factory and reintroduce them right after] 2. The subpackage is noarch and was published, then the i586/aarch64/etc. worker started building for a different target but otherwise same package (hence same %release), then that new noarch subpackage got published as part of aarch64/etc. publishing, and potentially overwriting the previous copy if the publisher does not stop this from happening. (considering #1, it probably does not)
Hi Andrei, On Thu, 2023-04-20 at 20:59 +0300, Andrei Borzenkov wrote:
The following 41 packages are going to be reinstalled: adwaita-qt5 boost-license1_81_0 gio-branding-openSUSE glibc glibc- extra glibc-locale glibc-locale-base gnome-menus-branding-openSUSE gtk2-branding-openSUSE gtk3-branding-openSUSE gtk4-branding- openSUSE libadwaitaqt5-1 libappindicator3-1 libboost_date_time1_81_0 libboost_date_time1_81_0-x86-64-v3 libboost_filesystem1_81_0 libboost_filesystem1_81_0-x86-64-v3 libboost_iostreams1_81_0 libboost_iostreams1_81_0-x86-64-v3 libboost_locale1_81_0 libboost_locale1_81_0-x86-64-v3 libboost_thread1_81_0 libboost_thread1_81_0-x86-64-v3 libdbusmenu-glib4 libdbusmenu- gtk3-4 libfftw3-3 libjavascriptcoregtk-4_1-0 libmetis5 libopenblas_pthreads0 libpoppler127 libpoppler-cpp0 libpoppler-glib8 libwebkit2gtk-4_1-0 NetworkManager-branding-openSUSE nscd poppler-tools QGnomePlatform-qt5 qtdeclarative-imports-provides-qt5 typelib-1_0-JavaScriptCore-4_1 typelib-1_0-WebKit2-4_1 webkit2gtk-4_1-injected-bundles
That's a weird side-effect of an error I did; An error in prjconf happened to be 'redefining the %if macro' which resulted in some spec file's %if …. BuildArch: do-not-build %endif totrigger even when the condition was not true. OBS interpreted my stupidity as 'exclude the package, remove the binaries' (you can imagine how happy I was to see this happening with glibc) Things could be corrected, OBS re-instated the builds as needed and (with some help) retriggered the builds of the earlier 'excluded' packages. A bit surprising, the rebuild counter has not been increased. There are safeguards being put in place to protect you from me - and such errors should be caught by OBS in the future (I'm sure there is plenty room for me to do other stupid mistakes though) Generally, we recovered rather good from it. The biggest worry with EVR not changing is that some mirrors might take a really long time to catch up (and the mirror infra believing things are synced which are not) Cheers, Dominique
participants (4)
-
Andrei Borzenkov
-
Dan Čermák
-
Dominique Leuenberger
-
Jan Engelhardt