Re: transition of packages into testing where Build-Depends can't be fulfilled for some architecture

2017-01-22 Thread Carsten Schoenert
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

2017-01-22 Thread Emilio Pozuelo Monfort
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

2017-01-18 Thread Carsten Schoenert
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