Control: tags -1 moreinfo Hi josch,
On 04-01-2020 22:13, Johannes Schauer wrote: > yes, I was aware of the introduction of libcrypt, that's why I uploaded > 0.5.1-3 > which addresses precisely this change. My naive assumption was, that once > libcrypt migrates to testing, mmdebstrap would migrate just fine. True, if you only look at mmdebstrap. > Thanks a lot for opening this bug report because apparently I have a > misunderstanding about how our CI and migration work together with automatic > migration and maybe you can help me clear up my understanding of it? :) However, there are cases where other packages are blocked due to the failure of mmdebstrap. Two examples: The last couple of days: shadow. shadow somehow triggers britney to add libcrypt from unstable to the set of packages to test, but NOT mmdebstrap. The test thus has delayed shadow from migration for about 10 days. Hence, tests like this are harmful for others. Now libcrypt1 migrated, but mmdebstrap did not (due to this bug, hence downgrading). The old package now fails in testing and that's something that we consider RC already. However, until the reference test is run, all packages that run mmdebstrap as test will be believed to cause regressions. Now, you can argue that changes to the base chroot are rare. I don't know but I could take your word for it. However, *if* they happen, like now, they do cause issues, like for shadow. If the situation prolongs, it triggers investigation by others that are not familiar with your test and it would require an overwrite from the release team if the situation was critical (e.g. shadow needed to migrate fast) or if it would have taken longer for libcrypt to finally migrate. Please consider your options carefully. I can live with you choosing to keep the test, but I think its smarter to not have these kind of tests as potential gating for migration of other package unless it's really worth it and rare. Paul
signature.asc
Description: OpenPGP digital signature