Hi, I might have a workaround, if ceph-dencoder is the only piece that fails.
Unfortunately I doubt it is, but I'll give it a try in experimental soon. Bernd Am 16. Jänner 2020 00:55:11 MEZ schrieb peter green <plugw...@p10link.net>: >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. -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
