testing migration errors about libqt4-webkit

[Daniel Pocock]

On 14/09/15 19:17, Adam D. Barratt wrote:
> On 2015-09-14 16:54, Daniel Pocock wrote:
>> On 14/09/15 17:34, Lisandro Damián Nicanor Pérez Meyer wrote:
>>> On Monday 14 September 2015 10:12:40 Daniel Pocock wrote:
>>>> https://release.debian.org/migration/testing.pl?package=postbooks tells
>>>> me that my package didn't migrate to testing because "libqt4-webkit is
>>>> not available in Debian"
> 
> Well, it also says "Updating postbooks makes 1 non-depending packages
> uninstallable on amd64: postbooks-updater", which is more relevant.
> 
>>>> I unpacked the binary package[1] with "dpkg -e ..." and looking inside
>>>> the control file, libqt4-webkit is not mentioned anywhere.  It only
>>>> depends on libqtwebkit4 (>= 2.1.0~2011week13)
> [...]
> 
> I'm not sure why it's getting the package name wrong, other than because
> the script needs rewriting from scratch (to handle multiple
> architectures (at least amd64), deal sensibly with extra-source-only,
> notice that the package is being auto-hinted, etc). If you want to know
> what's going on with britney, I'd suggest looking at output that's
> generated by britney (i.e. britney logs and/or grep-excuses).
> 

Currently, the "Check why" link on packages.qa.debian.org/postbooks
takes me to the testing.pl link above.  If that testing.pl script has a
lot of known issues, then maybe the "Check why" link should be removed?


> It's possible / probable that the "not available in Debian" is due to
> the fact that (as it says) the script only checks binary dependencies on
> i386, and postbooks doesn't build there.
> 

Where did you see that?  The buildd suggests it was built successfully
on i386:

https://buildd.debian.org/status/fetch.php?pkg=postbooks&arch=i386&ver=4.9.1-3&stamp=1441624363

>> Can anybody in the release team comment on this?
> 
> I have to admit that I'm failing to spot what the exact issue is, other
> than postbooks and postbooks-updater want to migrate to testing at the
> same time but don't have an explicit dependency relationship (and I
> believe that Niels has added a hint to achieve that while I was checking
> things and writing this reply).
>

postbooks-updater has
- a build dependency on the dev package from postbooks, debian/control
explicitly states:
       libxtuplecommon-dev (>= 4.9.1)
- a runtime dependency on one of the shared libs from postbooks, it is
added in debian/control by ${shlibs:Depends}

postbooks binary itself suggests postbooks-updater

Do I need to update the postbooks-updater package to use something more
than just ${shlibs:Depends} ?