Hi Nils, Niels Thykier <ni...@thykier.net> writes: > Ole Streicher: >> Andrey Rahmatullin <w...@debian.org> writes: >>> On Thu, Aug 17, 2017 at 08:42:37PM +0200, Ole Streicher wrote: > The package is affected by the same issue that chocolate-doom was in the > referenced bug (#824169). The situation in summary: > > * The source produces 1 or more binaries in "main" and 1 or more > binaries in "contrib" > > * During upload, dak can (mistakenly) end up putting the source in > both main and contrib at the same time. Technically, it ends up in > different suites (unstable vs unstable-debug), but these suites have > to agree.
Can't they be rmeoved manually here? Or with a dirty script as a workaround? > * Once britney requests dak to migrate the package to testing, dak > will notice the issue and reject the import (resulting in a > rollback of all changes to testing). > > * The quickest way to untangle the situation is to block the affected > package (i.e. ensure britney will not migrate it), so other packages > can migrate to testing. This is most likely why cpl is now blocked > by a manual hint. But this will prevent from fixing bugs of the package in testing, doing transisions etc. Currently the new package fixes a bug on armhf, which is not that important due to the limited user base, but for sure there will come RC bugs, transitions in this package (which then will also prevent the reverse dependencies to migrate), or even transitions in an dependent package (and then the transition will be stuck on a non-migratable package). The solution to block packages which are perfectly fine seems to be a quick, but also a dirty solution. Is there a reason why the bug severity is "important" and not "serious"? A bug that is preventing other packages from reaching "testing" (and, in a few years, "stable" aka then "buster") should be RC, shouldn't it? (And, shouldn't the affected packages be tagged as "affects" in the bug?) I am also wondering why this did not happen before? The cpl package structure is unchanged since years, without any reported problems. > With the situation clarified, here is how it can be fixed: > > 1a. Have dak patched so it does not do this again. Depending on the > exact implementation, it may need to be combined with 2). Once > that is resolved, it will also need 3) Which is nothing where I could do much, due to my non-existing dak knowledge. > 1b. Avoid having a source package that builds binaries in multiple > components. Sadly, this often implies duplicating the majority > of the source package. Combine with 2) + 3) Sounds like much work to work around a bug somewhere else. Especially when the bug is temporary; since then one would want to revert it after fixing. > 1c. *Maybe* the FTP masters can work around this (I don't remember) > on their side on a per package basis. This will need to be > combined with 2) (although, the FTP masters will probably do it > as the same time as this item) + 3). So, this seems to be the way to go, right? Shall I just open a bug for ftp-masters asking for unblock? Or what should I do here? Best regards Ole
