On 12/28/19 2:23 PM, Bernd Zeimetz wrote: > Hi, > >> I'd be IMO fine if we drop armel, armhf and mipsel, for the server side >> of things. I don't see how one could reliable setup a cluster with this >> type of CPUs in production anyway. > > ack. > > >> But IMO, it'd be nice if we could at least keep the client side working. >> I'm not sure how to achieve this though, probably this will make the >> build a lot more complicated. > > If you are keen on trying this, go on. I don't have enough spare time to > care of it. Might make sense to open an upstream bug report about it, > though. Supporting a client-only build should come from them imho, you > never know how the build system will change and if it is possible to > keep up support for it. > Which parts of the client side are you interested in? > I could imagine that building cephfs alone is possible.
I think it'd be nice if we could have at least: - cephfs - librbd (so that Qemu could be built with it) So, more or less, this means all the Package: lib*, no? >> BTW, any idea what dependency is missing in mips64el? > > https://buildd.debian.org/status/package.php?p=ceph > Dependency installability problem for ceph on mips64el: > ceph build-depends on missing: > - libboost-context-dev:mips64el (>= 1.67.0) > > (like on various other architectures) The buildd status page says it's currently in "building" status for the release -6 you've uploaded. So probably this has been solved. Let's see then! :) Cheers, Thomas Goirand (zigo)
