On 14/01/2020 10:24, Michael Tokarev wrote:
Control: severity -1 normal
Control: tag -1 + moreinfo
12.01.2020 18:37, peter green wrote:
Package: qemu-block-extra
Version: 1:4.2-1
Severity: serious
The binary packages built from the ceph source package were recently removed
from mipsel, because the new version of ceph runs out of address space
during the build. Your package build-depends on libradios-dev and librbd-dev
and depends on librados2 and librbd1 which are built from the ceph source
package. So qemu-block-extra is now uninstallable and the qemu source package
is unbuildable on mipsel.
Hm. For the start, I see that new ceph packages are being built on mips/mips64
right now as I write this. So things aren't that simple, at least.
Ceph 14.2.4 was uploaded to unstable in late december, but failed to build on many
architectures. The maintainer found workarounds for most of them, but could not find any
soloution to the address space exhaustion issue on mipsel (when a build says "out of
memory" it nearly always really means out of address space).
With version 14.2.4-8 the maintainer decided it was time to give up on mipsel,
he removed mipsel from the architecture lists and filed a removal request with
the ftp masters. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947887
It seems that with version 1.4.2.5-1 mipsel was quietly re-added to the
achitecture list, I do not know if this was a mistake or if the maintainer was
deliberately testing if the problem had gone away. Either way ceph has
continued to fail to build on mipsel.
Next, even if we're now uninstallable on some architecture, it is definitely not
our fault,
It's not about "fault".
so I don't see why this bugreport is of serious severity.
rc policy "Packages must be buildable within the same release."
I'm not going to play severity ping-pong with you, but I am ccing the ceph
maintainers and the release team in-case they want to give a position on this.
Also, it has
nothing to do with this particular version of qemu, either.
True enough, afaict normal practice is to file bugs against the current version
in testing/unstable unless there is reason not to.
And more, it has
nothing to do with qemu-block-extra package, too, even if that's the only pkg
which actually uses the library in question, -- we _build_-depend on
librados-dev
too, so it is qemu source which FTBFS on mips.
If you would preffer to reassign to the source package that is fine by me,
doesn't make much practical difference.
So far I don't quite understand what's going on with ceph on mips, hence adding
a "moreinfo" tag. We shouldn't drop optional features on different architectures
easily,
If I thought this was just some transient issue I wouldn't have bothered filing
this bug, but I doubt it is.
or else it would quickly become a mess, not understanding which features
of which packages are enabled on which architecture (I speak here about general
debian, not about this particular (pair of) package).
At some point I think Debian needs to have a hard think about how 32-bit
architectures are supported, possiblly introducing official support for
cross-building heavier packages, but so-far there doesn't seem to have been a
strong will to do so.
