Re: transition of packages into testing where Build-Depends can't be fulfilled for some architecture
Hello Emilo, Am 22.01.2017 um 23:36 schrieb Emilio Pozuelo Monfort: > Changing the architecture doesn't help and is not needed. You can revert that > in > your next upload. > > The issue is that the kicad-common package went from arch:all to arch:any, and > the arch:all package is still around. The arch:all package was available to > mips64el and s390x, and that confuses britney when switching to arch:any and > being unavailable on some architectures. > > The solution here is to file a removal bug for kicad-common_4.0.5+dfsg1-1 > against ftp.debian.org thanks for this helpful information! I wasn't aware of that reason why britney isn't showing the expected view. I will revert my last change about the architectures in a future upload. I think Adrian was much quicker than me about the removal request you suggested, thanks Adrian for filing the RM bug. https://bugs.debian.org/852262 -- Regards Carsten Schoenert
Re: transition of packages into testing where Build-Depends can't be fulfilled for some architecture
On 19/01/17 07:53, Carsten Schoenert wrote: > Hello, > > for some time I'm working on the package kicad [1] to help the current > maintainer Georges Khaznadar. Georges told me he currently haven't the > needed time to get kicad fully prepared for the Stretch release and > thankfully he gave me upload rights. > > So I worked on the latest release of KiCad v4.0.5 and prepared the > upload and changes for a Debian release. > > KiCad is using a lot of the Boost libraries, so the package > libboost-context-dev is also needed. > As I've now have seen boost changed [2] the supported platforms for this > package in 1.58.0.2 and only the platforms any-i386 any-amd64 armel > armhf arm64 mips mipsel powerpc ppc64el are now provided with a package > of libboost-context-dev. > > Thus kicad isn't build able on mips64el and s390x [3]. And some other > non RC platforms as well. So, now to my question, is this behavior > preventing kicad to migrate into testing after the delay? > Need I to change the Architecture field for the arch related packages of > kicad then accordingly? As we are going on to the 26th January I would > solve this issue before we would need to call for unblocking later. > Or would kicad enter testing automatically and no further action is need > for kicad? Changing the architecture doesn't help and is not needed. You can revert that in your next upload. The issue is that the kicad-common package went from arch:all to arch:any, and the arch:all package is still around. The arch:all package was available to mips64el and s390x, and that confuses britney when switching to arch:any and being unavailable on some architectures. The solution here is to file a removal bug for kicad-common_4.0.5+dfsg1-1 against ftp.debian.org Cheers, Emilio
transition of packages into testing where Build-Depends can't be fulfilled for some architecture
Hello, for some time I'm working on the package kicad [1] to help the current maintainer Georges Khaznadar. Georges told me he currently haven't the needed time to get kicad fully prepared for the Stretch release and thankfully he gave me upload rights. So I worked on the latest release of KiCad v4.0.5 and prepared the upload and changes for a Debian release. KiCad is using a lot of the Boost libraries, so the package libboost-context-dev is also needed. As I've now have seen boost changed [2] the supported platforms for this package in 1.58.0.2 and only the platforms any-i386 any-amd64 armel armhf arm64 mips mipsel powerpc ppc64el are now provided with a package of libboost-context-dev. Thus kicad isn't build able on mips64el and s390x [3]. And some other non RC platforms as well. So, now to my question, is this behavior preventing kicad to migrate into testing after the delay? Need I to change the Architecture field for the arch related packages of kicad then accordingly? As we are going on to the 26th January I would solve this issue before we would need to call for unblocking later. Or would kicad enter testing automatically and no further action is need for kicad? Thanks! [1] https://tracker.debian.org/pkg/kicad [2] http://metadata.ftp-master.debian.org/changelogs/main/b/boost-defaults/unstable_changelog https://sources.debian.net/src/boost-defaults/1.62.0.1/debian/control/#L200 [3] https://buildd.debian.org/status/package.php?p=kicad -- Regards Carsten Schoenert