Did solver.dupAllowVendorChange change? Dupe last night listed "Problems" for newer packages in alternate repositories?
All, Devs, zypper dupe last night was really odd from a "problems" and chose a solution standpoint. It seemed like zypper dup was ignoring my setting in zypp.conf of solver.dupAllowVendorChange = false It was suggesting overwriting OSS packages with packages from the science and mingw repositories. There were multiple packages where I had to tell the chooser to keep the OSS package and not pull the package from some other repo. I thought that setting prevented that. It also wanted suggested switching Nvidia drivers from my current repo to the openSUSE repo with lower version (newer package but lower release count). I was fine with the change, but was surprised that it too seemed to ignore the dupAllowVendorChange setting. Did something change how that setting works? -- David C. Rankin, J.D.,P.E.
30.11.2024 16:22, David C. Rankin wrote:
All, Devs,
zypper dupe last night was really odd from a "problems" and chose a solution standpoint. It seemed like zypper dup was ignoring my setting in zypp.conf of
solver.dupAllowVendorChange = false
It was suggesting overwriting OSS packages with packages from the science and mingw repositories. There were multiple packages where I had to tell the chooser to keep the OSS package and not pull the package from some other repo. I thought that setting prevented that.
It also wanted suggested switching Nvidia drivers from my current repo to the openSUSE repo with lower version (newer package but lower release count). I was fine with the change, but was surprised that it too seemed to ignore the dupAllowVendorChange setting.
Did something change how that setting works?
Show the full command line and the complete output.
On 11/30/24 7:33 AM, Andrei Borzenkov wrote:
Did something change how that setting works?
Show the full command line and the complete output.
Full Command Line: sudo zypper dup Output gone on reboot, but I can grab the logs -- they are quite chatty, I snipped the solver portion: https://paste.opensuse.org/pastes/e309e70064e4 If you need the whole thing, I'm happy to provide it. Just tell me where to post it. Log is 100822 lines total. -- David C. Rankin, J.D.,P.E.
30.11.2024 17:41, David C. Rankin wrote:
On 11/30/24 7:33 AM, Andrei Borzenkov wrote:
Did something change how that setting works?
Show the full command line and the complete output.
Full Command Line:
sudo zypper dup
Output gone on reboot, but I can grab the logs -- they are quite chatty, I snipped the solver portion:
https://paste.opensuse.org/pastes/e309e70064e4
If you need the whole thing, I'm happy to provide it. Just tell me where to post it. Log is 100822 lines total.
Picking at random
2024-11-29 21:30:12 <1> wizard(319160) [zypp::solver] SATResolver.cc(problems):1378 problem with the installed cura-4.13.1-2.7.noarch 2024-11-29 21:30:12 <1> wizard(319160) [zypp::solver] SATResolver.cc(problems):1379 ------------------------------------ 2024-11-29 21:30:13 <1> wizard(319160) [libsolv++] PoolImpl.cc(logSat):131 solver statistics: 0 learned rules, 1 unsolvable, 0 minimization steps 2024-11-29 21:30:13 <1> wizard(319160) [libsolv++] PoolImpl.cc(logSat):131 done solving. 2024-11-29 21:30:13 <1> wizard(319160) [libsolv++] PoolImpl.cc(logSat):131 2024-11-29 21:30:13 <1> wizard(319160) [libsolv++] PoolImpl.cc(logSat):131 solver statistics: 0 learned rules, 1 unsolvable, 0 minimization steps 2024-11-29 21:30:13 <1> wizard(319160) [libsolv++] PoolImpl.cc(logSat):131 done solving. 2024-11-29 21:30:13 <1> wizard(319160) [libsolv++] PoolImpl.cc(logSat):131 2024-11-29 21:30:13 <1> wizard(319160) [libsolv++] PoolImpl.cc(logSat):131 create_solutions for problem #8 took 19 ms 2024-11-29 21:30:13 <1> wizard(319160) [zypp::solver] SATResolver.cc(problems):1626 install cura-4.13.1-57.3.noarch from vendor obs://build.opensuse.org/science 2024-11-29 21:30:13 <1> wizard(319160) [zypp::solver] SATResolver.cc(problems):1626 replacing cura-4.13.1-2.7.noarch from vendor openSUSE 2024-11-29 21:30:13 <1> wizard(319160) [zypp::solver] SATResolver.cc(problems):1659 ------------------------------------ 2024-11-29 21:30:13 <1> wizard(319160) [zypp::solver] SATResolver.cc(problems):1555 keep obsolete cura-4.13.1-2.7.noarch 2024-11-29 21:30:13 <1> wizard(319160) [zypp::solver] SATResolver.cc(problems):1659 ------------------------------------
There is no package "cura" in Tumbleweed. So, there is really nothing for which to "preserve vendor". "zypper dup" by definition attempts to to match packages on your system to the enabled repositories. And yes, it is allowed to remove orphans when doing it.
On 11/30/24 9:07 AM, Andrei Borzenkov wrote:
2024-11-29 21:30:13 <1> wizard(319160) [zypp::solver] SATResolver.cc(problems):1626 install cura-4.13.1-57.3.noarch from vendor obs://build.opensuse.org/science 2024-11-29 21:30:13 <1> wizard(319160) [zypp::solver] SATResolver.cc(problems):1626 replacing cura-4.13.1-2.7.noarch from vendor openSUSE 2024-11-29 21:30:13 <1> wizard(319160) [zypp::solver] SATResolver.cc(problems):1659 ------------------------------------ 2024-11-29 21:30:13 <1> wizard(319160) [zypp::solver] SATResolver.cc(problems):1555 keep obsolete cura-4.13.1-2.7.noarch 2024-11-29 21:30:13 <1> wizard(319160) [zypp::solver] SATResolver.cc(problems):1659 ------------------------------------
There is no package "cura" in Tumbleweed. So, there is really nothing for which to "preserve vendor". "zypper dup" by definition attempts to to match packages on your system to the enabled repositories. And yes, it is allowed to remove orphans when doing it.
The mystery thickens, This was a fresh-install of TW in June. It lists cura as being from "vendor openSUSE" it wants to replace it with vendor obs://build.opensuse.org/science, where did the "vendor openSUSE" come from? -- David C. Rankin, J.D.,P.E.
30.11.2024 18:24, David C. Rankin wrote:
On 11/30/24 9:07 AM, Andrei Borzenkov wrote:
2024-11-29 21:30:13 <1> wizard(319160) [zypp::solver] SATResolver.cc(problems):1626 install cura-4.13.1-57.3.noarch from vendor obs://build.opensuse.org/science 2024-11-29 21:30:13 <1> wizard(319160) [zypp::solver] SATResolver.cc(problems):1626 replacing cura-4.13.1-2.7.noarch from vendor openSUSE 2024-11-29 21:30:13 <1> wizard(319160) [zypp::solver] SATResolver.cc(problems):1659 ------------------------------------ 2024-11-29 21:30:13 <1> wizard(319160) [zypp::solver] SATResolver.cc(problems):1555 keep obsolete cura-4.13.1-2.7.noarch 2024-11-29 21:30:13 <1> wizard(319160) [zypp::solver] SATResolver.cc(problems):1659 ------------------------------------
There is no package "cura" in Tumbleweed. So, there is really nothing for which to "preserve vendor". "zypper dup" by definition attempts to to match packages on your system to the enabled repositories. And yes, it is allowed to remove orphans when doing it.
The mystery thickens,
This was a fresh-install of TW in June. It lists cura as being from "vendor openSUSE" it wants to replace it with vendor obs://build.opensuse.org/science, where did the "vendor openSUSE" come from?
1218971 State:accepted By:anag+factory When:2024-11-06T15:51:14 Created by: dimstar_suse delete: openSUSE:Factory/cura Review by User is accepted: licensedigger(licensedigger) Review by User is accepted: factory-auto(factory-auto) Review by Group is accepted: factory-staging(anag+factory) Review by Package is accepted: science/cura(dimstar_suse) Review by Project is accepted: openSUSE:Factory:Staging:adi:42(anag+factory) Review by Group is accepted: factory-staging(anag+factory) Review by Project is accepted: openSUSE:Factory:Staging:adi:19(anag+factory) Descr: Removal needed, as uranium fails to build and no fix in sight; relates to sr#1217126 Comment: Staging Project openSUSE:Factory:Staging:adi:19 got accepted.
On 11/30/24 10:50 AM, Andrei Borzenkov wrote:
There is no package "cura" in Tumbleweed. So, there is really nothing for which to "preserve vendor". "zypper dup" by definition attempts to to match packages on your system to the enabled repositories. And yes, it is allowed to remove orphans when doing it.
The mystery thickens,
This was a fresh-install of TW in June. It lists cura as being from "vendor openSUSE" it wants to replace it with vendor obs://build.opensuse.org/science, where did the "vendor openSUSE" come from?
1218971 State:accepted By:anag+factory When:2024-11-06T15:51:14 Created by: dimstar_suse delete: openSUSE:Factory/cura Review by User is accepted: licensedigger(licensedigger) Review by User is accepted: factory-auto(factory-auto) Review by Group is accepted: factory-staging(anag+factory) Review by Package is accepted: science/cura(dimstar_suse) Review by Project is accepted: openSUSE:Factory:Staging:adi:42(anag+factory) Review by Group is accepted: factory-staging(anag+factory) Review by Project is accepted: openSUSE:Factory:Staging:adi:19(anag+factory) Descr: Removal needed, as uranium fails to build and no fix in sight; relates to sr#1217126 Comment: Staging Project openSUSE:Factory:Staging:adi:19 got accepted.
Ah hah!, Well done. So I'm not senile, there was a cura, now there is no cura (uranium to blame), and the science repo is the only one with a building cura at the time. All makes sense for those 2 problems listed in the output. The problems related to removal and braking php are the subject of the other thread, and then Nvidia problems and moving to the openSUSE packages were just a date issue (newer) despite the lower release point in the version number. Good to know both are checked. Thank you! -- David C. Rankin, J.D.,P.E.
participants (2)
-
Andrei Borzenkov -
David C. Rankin