reopen 893125 thanks In data mercoledì 21 marzo 2018 18:35:41 CET, Scott Kitterman ha scritto: > On Fri, 16 Mar 2018 18:15:40 +0100 Pino Toscano <p...@debian.org> wrote: > > Package: ftp.debian.org > > Severity: normal > > > > Hi, > > > > please decruft the old sources and binaries of src:calligra, as they > > do not seem to be cleaned automatically: > > $ rmadison -s unstable calligra > > calligra | 1:2.9.11+dfsg1-1 | unstable | source, all > > calligra | 1:3.0.1+dfsg-2 | unstable | source, all > > calligra | 1:3.1.0+dfsg-2 | unstable | source, all > > > > It looks like this prevents calligra 1:3.1.0+dfsg-2 to migrate to > > testing... > > I've gone ahead and removed all the arch specific binaries that were holding > the older versions in the archive, so they should be automatically decrufted > now, but they were all on non-release archs, so I don't think that's your > problem.
Apparently not:
* source package calligra version 1:3.1.0+dfsg-2 no longer builds
binary package(s): braindump
on amd64,arm64,armel,armhf,i386,mips,mips64el,mipsel,powerpc,ppc64el,s390x
- suggested command:
dak rm -m "[auto-cruft] NBS (no longer built by calligra)" -s unstable -a
amd64,arm64,armel,armhf,i386,mips,mips64el,mipsel,powerpc,ppc64el,s390x -p -R
-b braindump
- No dependency problem found
> I'm not an expert on reading britney output, but it looks to me like calligra
> is likely entangled with the libpoppler transition and that's a better place
> to look for the hold up.
Hm poppler migrated to testing 9 days ago, so I don't think that's the
actual issue; even reading the britney log, it refers to libpoppler72,
which was the old SONAME, while the build logs clearly show libpoppler73
as both installed and dependency.
So maybe really removing all of calligra 1:3.0.1+dfsg-2 (source + all
the binaries) will help...
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
