On 2025-02-04 11:43, Philipp Kern wrote:
> On 2025-02-04 08:22, Emilio Pozuelo Monfort wrote:
> > On 04/02/2025 01:53, Adrian Bunk wrote:
> > > On Mon, Feb 03, 2025 at 11:11:44PM +0100, Philipp Kern wrote:
> > > > On 2/3/25 3:03 PM, Alexandre Rossi wrote:
> > > > ...
> > > > > 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[...],
> > > > ...
> > >
> > > That's what the package already does, and it is working.
> > >
> > > The root problem is that it is fundamentally impossible to reliably
> > > guess the versions of the binary packages built by a source package,
> > > since these can be set to any value during the build and many packages
> > > in the archive include the versions of build dependencies into the
> > > versions of their binary packages.
> > >
> > > wanna-build might not have a better option here than assuming
> > > binary version = source version, but that's not 100% reliable.
> >
> > Why doesn't it just build the package? If it later then gets rejected,
> > then so be it. It wouldn't be much different than wanna-build
> > "rejecting" it (except for saving a few build cycles, but then a
> > situation like this has already wasted a lot of developer cycles). I'm
> > sure there's a good reason for the check, I suppose I'm just missing
> > it...
>
> Because wanna-build has no state. It diffs to see if the source package has
> been built. Does dpkg write out a "Source: package (= ${Source-Version})" if
> the version is different? I faintly recall such a thing. In that case we'd
Yes, it is actually the case, but that only happens once the package has
been built one.
> technically have enough information to at least associate the built binary
> back to the source package version to mark it as "Installed". But in general
> it just looks what's missing in a suite instead of creating a build task
> when it first sees a source package version. A lot of this is due to the
> fact that the archive and autobuilding are distinct systems. Otherwise an
> upload would just cause a build entry and we'd be done with it.
As long as the resulting build is not lost and always accepted.
> Also as I remember it it's not guaranteed that there is only one source
> package in a suite for a given name. So we'd need to always insert the
> highest into the DB and check if any of the binary packages it builds is
> already there.
That's exactly the problem we have here. The old uwsgi-plugin-* binary
packages are still in the archive as cruft, and also the old uwsgi
source version matching those.
The other way to solve that issue here would have been to ask ftpmasters
to remove the binary packages (and automatically the corresponding
source package) from the archive and wanna-build would have been able to
find that the uwsgi-plugin-* source package needs to get build.
IIRC, it is also possible to have a binary package built by different
source packages depending on the architecture.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
