Re: Package not migrating
Ole Streicher:
> Hi Nils,
>
Hi,
> Niels Thykier <niels@thykier.net> writes:
>> Ole Streicher:
>>> Andrey Rahmatullin <wrar@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?
>
No clue; I do not understand the technical details of the problem except
what I already wrote.
Based on the rest of your mail, I suspect I should clarify that I wrote
the mail to assist you with understand the problem. However, I have
very little Debian-related time/energy, so please forgive my lack of
activity in relation to this problem.
If you want this resolved in any timely fashion, your best bet is to
engage with the relevant parties.
>> * 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, [...]
Correct.
> The solution to block packages which are
> perfectly fine seems to be a quick, but also a dirty solution.
>
It is a work around. The release team have to choose between holding
testing hostage to this bug or just hold the package hostage (and
possibly related packages). As the latter is a vastly smaller subset of
the former, this is a rather trivial choice.
> [...]
> (And, shouldn't the affected packages be tagged as "affects" in the bug?)
>
I think you would be quite justified to add that relation.
> I am also wondering why this did not happen before? The cpl package
> structure is unchanged since years, without any reported problems.
>
I think the problem is non-deterministic.
>> 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.
>
I listed it as a possible solution in case you (or someone else on the
list) felt like challenge to improve our infrastructure tools. It is
fine if no one are up to for the challenge; it just means we will live
with this bug in dak a while longer. :)
> [...]
>> 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
>
Please contact the FTP team saying that your package is also affected by
#824169 and (with them) figure out how to solve it. But most likely,
you will get a work around (one way or another) in the absence of a
volunteer to fix dak.
/Once/ that is solved, contact the release team to remove the work
around we applied.
Thanks,
~Niels
Reply to: