https://bugzilla.suse.com/show_bug.cgi?id=1199895 https://bugzilla.suse.com/show_bug.cgi?id=1199895#c17 Michael Andres <ma@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo? --- Comment #17 from Michael Andres <ma@suse.com> --- (In reply to Jonathan Kang from comment #16)

... I think the problem is that they gained "ToBeInstall" status even they were locked, after doing a "resolver->doUpgrade()" for tumbleweed.

I can hardly imagine how this should happen in PK only. If a locked package has to be amended, the resolver will raise the problem and someone has to select the appropriate solution ('removing the lock' rather than 'drop the jpb'). Is someone able to reproduce it or has a system where this happened? If resolver->doUpgrade() (DUP) was called and the result is committed, zypp should auto-write a testcase. The testcase is named /var/log/updateTestcase-YYYY-MM-DD-hh-mm-ss (date the dup was performed). The pk_backend_zypp[_#] log should also show a line like

... [zypp] Testcase.cc(createTestcase):388 createTestcase done at /var/log/updateTestcase-2022-07-07-11-06-04 if a testcase was written.

If one is available somewhere, it should reveal what happenend during DUP. The corresponding pk_backend_zypp log would be helpfull as well. -- You are receiving this mail because: You are on the CC list for the bug.