On 2/3/25 3:03 PM, Alexandre Rossi wrote:
>>> Some uwsgi-plugin-* packages have not been built for a reason I have note
>>> been
>>> able to understand. Anyway, they need to be given back.
>>>
>>> gb uwsgi-plugin-gccgo_0.0.2 . ANY
>>> gb uwsgi-plugin-glusterfs_0.0.2 . ANY
>>> gb uwsgi-plugin-lua_0.0.2 . ANY
>>> gb uwsgi-plugin-psgi_0.0.2 . ANY
>>> gb uwsgi-plugin-python_0.0.2 . ANY
>>> gb uwsgi-plugin-rados_0.0.2 . ANY
>>
>> They can't be given back as they don't exist in the database. So that
>> needs to be debugged first.
>
> If this can help, those new source packages build binary packages that were
> previously built by src:uwsgi. For instance, src:uwsgi-plugin-gccgo builds
> uwsgi-plugin-gccgo. uwsgi-plugin-gccgo was built by src:uwsgi in previous
> versions.
>
> For similar changes in which the binary packages names were also changed,
> there is no problem, they were correctly built (uwsgi-plugin-{java,ruby}
> and uwsgi-plugin-pypy is completely new).
Yup, and this can never work. You need to build binary packages with a
version higher than what's in the archive. The archive would otherwise
reject it if it were to be built.
> $ rmadison -s unstable uwsgi-plugin-gccgo
> uwsgi-plugin-gccgo | 0.0.2 | unstable | source
> uwsgi-plugin-gccgo | 2.0.28-1+b2 | unstable | armel, armhf, i386,
> riscv64, s390x
> uwsgi-plugin-gccgo | 2.0.28+8+0.0.2 | unstable | amd64, arm64, mips64el,
> ppc64el
So you need to either produce a binary version that's higher than
2.0.28[...], or you need to adjust your source version to match that.
I'd assume that wanna-build would not know if you pick the "let's make
it a different binary version at build time" so bumping the source
version would be required.
(If you intend to use an epoch to reset versioning, clear that with
d-devel@ first.)
Kind regards
Philipp Kern
